1. Expressive Power
How do the sets of systems that models can describe compare?
If HRU equivalent to SPM, SPM provides more specific answer to safety question
If HRU describes more systems, SPM applies only to the systems it can describe

2. HRU vs. SPM SPM more abstract HRU allows revocation
Analyses focus on limits of model, not details of representation
HRU allows revocation
SMP has no equivalent to delete, destroy
HRU allows multiparent creates
SPM cannot express multiparent creates easily, and not at all if the parents are of different types because can•create allows for only one type of creator
April 13, 2004
ECS 235

3. Multiparent Create Solves mutual suspicion problem In HRU:
Create proxy jointly, each gives it needed rights
In HRU:
command multicreate(s0, s1, o)
if r in a[s0, s1] and r in a[s1, s0]
then
create object o;
enter r into a[s0, o];
enter r into a[s1, o];
end
April 13, 2004
ECS 235

4. SPM and Multiparent Create
can•create extended in obvious way
cc  TS  …  TS  T
Symbols
X1, …, Xn parents, Y created
R1,i, R2,i, R3, R4,i  R
Rules
crP,i((X1), …, (Xn)) = Y/R1,1  Xi/R2,i
crC((X1), …, (Xn)) = Y/R3  X1/R4,1  …  Xn/R4,n
April 13, 2004
ECS 235

5. Example Anna, Bill must do something cooperatively
But they don’t trust each other
Jointly create a proxy
Each gives proxy only necessary rights
In ESPM:
Anna, Bill type a; proxy type p; right x  R
cc(a, a) = p
crAnna(a, a, p) = crBill(a, a, p) = 
crproxy(a, a, p) = { Anna/x, Bill/x }
April 13, 2004
ECS 235

6. 2-Parent Joint Create Suffices
Goal: emulate 3-parent joint create with 2-parent joint create
Definition of 3-parent joint create (subjects P1, P2, P3; child C):
cc((P1), (P2), (P3)) = Z  T
crP1((P1), (P2), (P3)) = C/R1,1  P1/R2,1
crP2((P1), (P2), (P3)) = C/R2,1  P2/R2,2
crP3((P1), (P2), (P3)) = C/R3,1  P3/R2,3
April 13, 2004
ECS 235

7. General Approach Define agents for parents and child
Agents act as surrogates for parents
If create fails, parents have no extra rights
If create succeeds, parents, child have exactly same rights as in 3-parent creates
Only extra rights are to agents (which are never used again, and so these rights are irrelevant)
April 13, 2004
ECS 235

8. Entities and Types Parents P1, P2, P3 have types p1, p2, p3
Child C of type c
Parent agents A1, A2, A3 of types a1, a2, a3
Child agent S of type s
Type t is parentage
if X/t  dom(Y), X is Y’s parent
Types t, a1, a2, a3, s are new types
April 13, 2004
ECS 235

9. Can•Create Following added to can•create: cc(p1) = a1 cc(p2, a1) = a2
Parents creating their agents; note agents have maximum of 2 parents
cc(a3) = s
Agent of all parents creates agent of child
cc(s) = c
Agent of child creates child
April 13, 2004
ECS 235

10. Creation Rules Following added to create rule: crP(p1, a1) = 
crC(p1, a1) = p1/Rtc
Agent’s parent set to creating parent; agent has all rights over parent
crPfirst(p2, a1, a2) = 
crPsecond(p2, a1, a2) = 
crC(p2, a1, a2) = p2/Rtc  a1/tc
Agent’s parent set to creating parent and agent; agent has all rights over parent (but not over agent)
April 13, 2004
ECS 235

11. Creation Rules crPfirst(p3, a2, a3) =  crPsecond(p3, a2, a3) = 
crC(p3, a2, a3) = p3/Rtc  a2/tc
Agent’s parent set to creating parent and agent; agent has all rights over parent (but not over agent)
crP(a3, s) = 
crC(a3, s) = a3/tc
Child’s agent has third agent as parent crP(a3, s) = 
crP(s, c) = C/Rtc
crC(s, c) = c/R3t
Child’s agent gets full rights over child; child gets R3 rights over agent
April 13, 2004
ECS 235

12. Link Predicates Idea: no tickets to parents until child created
Done by requiring each agent to have its own parent rights
link1(A1, A2) = A1/t  dom(A2)  A2/t  dom(A2)
link1(A2, A3) = A2/t  dom(A3)  A3/t  dom(A3)
link2(S, A3) = A3/t  dom(S)  C/t  dom(C)
link3(A1, C) = C/t  dom(A1)
link3(A2, C) = C/t  dom(A2)
link3(A3, C) = C/t  dom(A3)
link4(A1, P1) = P1/t  dom(A1)  A1/t  dom(A1)
link4(A2, P2) = P2/t  dom(A2)  A2/t  dom(A2)
link4(A3, P3) = P3/t  dom(A3)  A3/t  dom(A3)
April 13, 2004
ECS 235

13. Filter Functions f1(a2, a1) = a1/t  c/Rtc f1(a3, a2) = a2/t  c/Rtc
f2(s, a3) = a3/t  c/Rtc
f3(a1, c) = p1/R4,1
f3(a2, c) = p2/R4,2
f3(a3, c) = p3/R4,3
f4(a1, p1) = c/R1,1  p1/R2,1
f4(a2, p2) = c/R1,2  p2/R2,2
f4(a3, p3) = c/R1,3  p3/R2,3
April 13, 2004
ECS 235

14. Construction Create A1, A2, A3, S, C; then P1 has no relevant tickets
A1 has P1/Rtc
A2 has P2/Rtc  A1/tc
A3 has P3/Rtc  A2/tc
S has A3/tc  C/Rtc
C has C/R3
April 13, 2004
ECS 235

15. Construction Only link2(S, A3) true  apply f2
A3 has P3/Rtc  A2/t  A3/t  C/Rtc
Now link1(A3, A2) true  apply f1
A2 has P2/Rtc  A1/tc  A2/t  C/Rtc
Now link1(A2, A1) true  apply f1
A1 has P2/Rtc  A1/tc  A1/t  C/Rtc
Now all link3s true  apply f3
C has C/R3  P1/R4,1  P2/R4,2  P3/R4,3
April 13, 2004
ECS 235

16. Finish Construction Now link4s true  apply f4
P1 has C/R1,1  P1/R2,1
P2 has C/R1,2  P2/R2,2
P3 has C/R1,3  P3/R2,3
3-parent joint create gives same rights to P1, P2, P3, C
If create of C fails, link2 fails, so construction fails
April 13, 2004
ECS 235

17. Theorem
The two-parent joint creation operation can implement an n-parent joint creation operation with a fixed number of additional types and rights, and augmentations to the link predicates and filter functions.
Proof: by construction, as above
Difference is that the two systems need not start at the same initial state
April 13, 2004
ECS 235

18. Theorems Monotonic ESPM and the monotonic HRU model are equivalent.
Safety question in ESPM also decidable if acyclic attenuating scheme
April 13, 2004
ECS 235

19. Expressiveness Graph-based representation to compare models Graph
Vertex: represents entity, has static type
Edge: represents right, has static type
Graph rewriting rules:
Initial state operations create graph in a particular state
Node creation operations add nodes, incoming edges
Edge adding operations add new edges between existing vertices
April 13, 2004
ECS 235

20. Example: 3-Parent Joint Creation
Simulate with 2-parent
Nodes P1, P2, P3 parents
Create node C with type c with edges of type e
Add node A1 of type a and edge from P1 to A1 of type e´
April 13, 2004
ECS 235

21. Next Step A1, P2 create A2; A2, P3 create A3
Type of nodes, edges are a and e´
April 13, 2004
ECS 235

22. Next Step A3 creates S, of type a S creates C, of type c P3 P1 P2 A3
April 13, 2004
ECS 235

23. Last Step Edge adding operations: P1A1A2A3SC: P1 to C edge type e
P2A2A3SC: P2 to C edge type e
P3A3SC: P3 to C edge type e P3 P1 P2 A2 A3 A1 S C
April 13, 2004
ECS 235

24. Definitions Scheme: graph representation as above
Model: set of schemes
Schemes A, B correspond if graph for both is identical when all nodes with types not in A and edges with types in A are deleted
April 13, 2004
ECS 235

25. Example Above 2-parent joint creation simulation in scheme TWO
Equivalent to 3-parent joint creation scheme THREE in which P1, P2, P3, C are of same type as in TWO, and edges from P1, P2, P3 to C are of type e, and no types a and e´ exist in TWO
April 13, 2004
ECS 235

26. Simulation Scheme A simulates scheme B iff
every state B can reach has a corresponding state in A that A can reach; and
every state that A can reach either corresponds to a state B can reach, or has a successor state that corresponds to a state B can reach
The last means that A can have intermediate states not corresponding to states in B, like the intermediate ones in TWO in the simulation of THREE
April 13, 2004
ECS 235

27. Expressive Power
If scheme in MA no scheme in MB can simulate, MB less expressive than MA
If every scheme in MA can be simulated by a scheme in MB, MB as expressive as MA
If MA as expressive as MB and vice versa, MA and MB equivalent
April 13, 2004
ECS 235

28. Example Scheme A in model M Scheme B in model N
Nodes X1, X2, X3
2-parent joint create
1 node type, 1 edge type
No edge adding operations
Initial state: X1, X2, X3, no edges
Scheme B in model N
All same as A except no 2-parent joint create
1-parent create
Which is more expressive?
April 13, 2004
ECS 235

29. Can A Simulate B?
Scheme A simulates 1-parent create: have both parents be same node
Model M as expressive as model N
April 13, 2004
ECS 235

30. Can B Simulate A? Suppose X1, X2 jointly create Y in A
Edges from X1, X2 to Y, no edge from X3 to Y
Can B simulate this?
Without loss of generality, X1 creates Y
Must have edge adding operation to add edge from X2 to Y
One type of node, one type of edge, so operation can add edge between any 2 nodes
April 13, 2004
ECS 235

31. No All nodes in A have even number of incoming edges
2-parent create adds 2 incoming edges
Edge adding operation in B that can edge from X2 to C can add one from X3 to C
A cannot enter this state
B cannot transition to a state in which Y has even number of incoming edges
No remove rule
So B cannot simulate A; N less expressive than M
April 13, 2004
ECS 235

32. Theorem
Monotonic single-parent models are less expressive than monotonic multiparent models
ESPM more expressive than SPM
ESPM multiparent and monotonic
SPM monotonic but single parent
April 13, 2004
ECS 235

33. Typed Access Matrix Model
Like ACM, but with set of types T
All subjects, objects have types
Set of types for subjects TS
Protection state is (S, O, , A), where :OT specifies type of each object
If X subject, (X) in TS
If X object, (X) in T – TS
April 13, 2004
ECS 235

34. Create Rules Subject creation Object creation
create subject s of type ts
s must not exist as subject or object when operation executed
ts  TS
Object creation
create object o of type to
o must not exist as subject or object when operation executed
to  T – TS
April 13, 2004
ECS 235

35. Create Subject Precondition: s  S
Primitive command: create subject s of type t
Postconditions:
S´ = S  { s }, O´ = O  { s }
(y  O)[´(y) =  (y)], ´(s) = t
(y  O´)[a´[s, y] = ], (x  S´)[a´[x, s] = ]
(x  S)(y  O)[a´[x, y] = a[x, y]]
April 13, 2004
ECS 235

36. Create Object Precondition: o  O
Primitive command: create object o of type t
Postconditions:
S´ = S, O´ = O  { o }
(y  O)[´(y) =  (y)], ´(o) = t
(x  S´)[a´[x, o] = ]
(x  S)(y  O)[a´[x, y] = a[x, y]]
April 13, 2004
ECS 235

37. Definitions MTAM Model: TAM model without delete, destroy
MTAM is Monotonic TAM
(x1:t1, ..., xn:tn) create command
ti child type in  if any of create subject xi of type ti or create object xi of type ti occur in 
ti parent type otherwise
April 13, 2004
ECS 235

38. Cyclic Creates
command havoc(s1 : u, s2 : u, o1 : v, o2 : v, o3 : w, o4 : w)
create subject s1 of type u;
create object o1 of type v;
create object o3 of type w;
enter r into a[s2, s1];
enter r into a[s2, o2];
enter r into a[s2, o4]
end
April 13, 2004
ECS 235

39. Creation Graph u, v, w child types u, v, w also parent types
Graph: lines from parent types to child types
This one has cycles u v w
April 13, 2004
ECS 235

40. Theorems Safety decidable for systems with acyclic MTAM schemes
Safety for acyclic ternary MATM decidable in time polynomial in the size of initial ACM
“ternary” means commands have no more than 3 parameters
Equivalent in expressive power to MTAM
April 13, 2004
ECS 235

41. Key Points Safety problem undecidable
Limiting scope of systems can make problem decidable
Types critical to safety problem’s analysis
April 13, 2004
ECS 235

42. Overview Overview Policies Trust Nature of Security Mechanisms
Policy Expression Languages
Limits on Secure and Precise Mechanisms
April 13, 2004
ECS 235

43. Security Policy Policy partitions system states into: Secure system
Authorized (secure)
These are states the system can enter
Unauthorized (nonsecure)
If the system enters any of these states, it’s a security violation
Secure system
Starts in authorized state
Never enters unauthorized state
April 13, 2004
ECS 235

44. Confidentiality X set of entities, I information
I has confidentiality property with respect to X if no x in X can obtain information from I
I can be disclosed to others
Example:
X set of students
I final exam answer key
I is confidential with respect to X if students cannot obtain final exam answer key
April 13, 2004
ECS 235

45. Integrity X set of entities, I information
I has integrity property with respect to X if all x in X trust information in I
Types of integrity:
trust I, its conveyance and protection (data integrity)
I information about origin of something or an identity (origin integrity, authentication)
I resource: means resource functions as it should (assurance)
April 13, 2004
ECS 235

46. Availability X set of entities, I resource
I has availability property with respect to X if all x in X can access I
Types of availability:
traditional: x gets access or not
quality of service: promised a level of access (for example, a specific level of bandwidth) and not meet it, even though some access is achieved
April 13, 2004
ECS 235

47. Policy Models Abstract description of a policy or class of policies
Focus on points of interest in policies
Security levels in multilevel security models
Separation of duty in Clark-Wilson model
Conflict of interest in Chinese Wall model
April 13, 2004
ECS 235

48. Types of Security Policies
Military (governmental) security policy
Policy primarily protecting confidentiality
Commercial security policy
Policy primarily protecting integrity
Confidentiality policy
Policy protecting only confidentiality
Integrity policy
Policy protecting only integrity
April 13, 2004
ECS 235

49. Integrity and Transactions
Begin in consistent state
“Consistent” defined by specification
Perform series of actions (transaction)
Actions cannot be interrupted
If actions complete, system in consistent state
If actions do not complete, system reverts to beginning (consistent) state
April 13, 2004
ECS 235

50. Trust Administrator installs patch
Trusts patch came from vendor, not tampered with in transit
Trusts vendor tested patch thoroughly
Trusts vendor’s test environment corresponds to local environment
Trusts patch is installed correctly
April 13, 2004
ECS 235

51. Trust in Formal Verification
Gives formal mathematical proof that given input i, program P produces output o as specified
Suppose a security-related program S formally verified to work with operating system O
What are the assumptions?
April 13, 2004
ECS 235

52. Trust in Formal Methods
Proof has no errors
Bugs in automated theorem provers
Preconditions hold in environment in which S is to be used
S transformed into executable S’ whose actions follow source code
Compiler bugs, linker/loader/library problems
Hardware executes S’ as intended
Hardware bugs (Pentium f00f bug, for example)
April 13, 2004
ECS 235

53. Types of Access Control
Discretionary Access Control (DAC, IBAC)
individual user sets access control mechanism to allow or deny access to an object
Mandatory Access Control (MAC)
system mechanism controls access to object, and individual cannot alter that access
Originator Controlled Access Control (ORCON)
originator (creator) of information controls who can access information
April 13, 2004
ECS 235

54. Question Policy disallows cheating
Includes copying homework, with or without permission
CS class has students do homework on computer
Anne forgets to read-protect her homework file
Bill copies it
Who cheated?
Anne, Bill, or both?
April 13, 2004
ECS 235

55. Answer Part 1 Bill cheated
Policy forbids copying homework assignment
Bill did it
System entered unauthorized state (Bill having a copy of Anne’s assignment)
If not explicit in computer security policy, certainly implicit
Not credible that a unit of the university allows something that the university as a whole forbids, unless the unit explicitly says so
April 13, 2004
ECS 235

56. Answer Part #2 Anne didn’t protect her homework
Not required by security policy
She didn’t breach security
If policy said students had to read-protect homework files, then Anna did breach security
She didn’t do so
April 13, 2004
ECS 235

57. Mechanisms
Entity or procedure that enforces some part of the security policy
Access controls (like bits to prevent someone from reading a homework file)
Disallowing people from bringing CDs and floppy disks into a computer facility to control what is placed on systems
April 13, 2004
ECS 235

58. Overview Key exchange Cryptographic key infrastructure Key storage
Session vs. interchange keys
Classical, public key methods
Key generation
Cryptographic key infrastructure
Certificates
Key storage
Key escrow
Key revocation
Digital signatures
May 13, 2004
ECS 235

59. Notation X  Y : { Z || W } kX,Y A  T : { Z } kA || { W } kA,T
X sends Y the message produced by concatenating Z and W enciphered by key kX,Y, which is shared by users X and Y
A  T : { Z } kA || { W } kA,T
A sends T a message consisting of the concatenation of Z enciphered using kA, A’s key, and W enciphered using kA,T, the key shared by A and T
r1, r2 nonces (nonrepeating random numbers)
May 13, 2004
ECS 235

60. Session, Interchange Keys
Alice wants to send a message m to Bob
Assume public key encryption
Alice generates a random cryptographic key ks and uses it to encipher m
To be used for this message only
Called a session key
She enciphers ks with Bob;s public key kB
kB enciphers all session keys Alice uses to communicate with Bob
Called an interchange key
Alice sends { m } ks { ks } kB
May 13, 2004
ECS 235

61. Benefits Limits amount of traffic enciphered with single key
Standard practice, to decrease the amount of traffic an attacker can obtain
Prevents some attacks
Example: Alice will send Bob message that is either “BUY” or “SELL”. Eve computes possible ciphertexts { “BUY” } kB and { “SELL” } kB. Eve intercepts enciphered message, compares, and gets plaintext at once
May 13, 2004
ECS 235

62. Key Exchange Algorithms
Goal: Alice, Bob get shared key
Key cannot be sent in clear
Attacker can listen in
Key can be sent enciphered, or derived from exchanged data plus data not known to an eavesdropper
Alice, Bob may trust third party
All cryptosystems, protocols publicly known
Only secret data is the keys, ancillary information known only to Alice and Bob needed to derive keys
Anything transmitted is assumed known to attacker
May 13, 2004
ECS 235

63. Classical Key Exchange
Bootstrap problem: how do Alice, Bob begin?
Alice can’t send it to Bob in the clear!
Assume trusted third party, Cathy
Alice and Cathy share secret key kA
Bob and Cathy share secret key kB
Use this to exchange shared key ks
May 13, 2004
ECS 235

64. Simple Protocol { request for session key to Bob } kA Alice Cathy
{ ks } kA || { ks } kB
Alice
Cathy
{ ks } kB
Alice
Bob
May 13, 2004
ECS 235

65. Problems How does Bob know he is talking to Alice?
Replay attack: Eve records message from Alice to Bob, later replays it; Bob may think he’s talking to Alice, but he isn’t
Session key reuse: Eve replays message from Alice to Bob, so Bob re-uses session key
Protocols must provide authentication and defense against replay
May 13, 2004
ECS 235

66. Needham-Schroeder Alice || Bob || r1 Alice Cathy
{ Alice || Bob || r1 || ks || { Alice || ks } kB } kA
Alice
Cathy
{ Alice || ks } kB
Alice
Bob
{ r2 } ks
Alice
Bob
{ r2 – 1 } ks
Alice
Bob
May 13, 2004
ECS 235

67. Argument: Alice talking to Bob
Second message
Enciphered using key only she, Cathy know
So Cathy enciphered it
Response to first message
As r1 in it matches r1 in first message
Third message
Alice knows only Bob can read it
As only Bob can derive session key from message
Any messages enciphered with that key are from Bob
May 13, 2004
ECS 235

68. Argument: Bob talking to Alice
Third message
Enciphered using key only he, Cathy know
So Cathy enciphered it
Names Alice, session key
Cathy provided session key, says Alice is other party
Fourth message
Uses session key to determine if it is replay from Eve
If not, Alice will respond correctly in fifth message
If so, Eve can’t decipher r2 and so can’t respond, or responds incorrectly
May 13, 2004
ECS 235

69. Denning-Sacco Modification
Assumption: all keys are secret
Question: suppose Eve can obtain session key. How does that affect protocol?
In what follows, Eve knows ks
{ Alice || ks } kB
Eve
Bob
{ r2 } ks
Eve
Bob
{ r2 – 1 } ks
Eve
Bob
May 13, 2004
ECS 235

70. Solution In protocol above, Eve impersonates Alice
Problem: replay in third step
First in previous slide
Solution: use time stamp T to detect replay
Weakness: if clocks not synchronized, may either reject valid messages or accept replays
Parties with either slow or fast clocks vulnerable to replay
Resetting clock does not eliminate vulnerability
May 13, 2004
ECS 235

71. Needham-Schroeder with Denning-Sacco Modification
Alice || Bob || r1
Alice
Cathy
{ Alice || Bob || r1 || ks || { Alice || T || ks } kB } kA
Alice
Cathy
{ Alice || T || ks } kB
Alice
Bob
{ r2 } ks
Alice
Bob
{ r2 – 1 } ks
Alice
Bob
May 13, 2004
ECS 235

72. Otway-Rees Protocol Corrects problem Does not use timestamps
That is, Eve replaying the third message in the protocol
Does not use timestamps
Not vulnerable to the problems that Denning-Sacco modification has
Uses integer n to associate all messages with particular exchange
May 13, 2004
ECS 235

73. The Protocol n || Alice || Bob || { r1 || n || Alice || Bob } kA Alice
{ r2 || n || Alice || Bob } kB
Cathy
Bob
n || { r1 || ks } kA || { r2 || ks } kB
Cathy
Bob
n || { r1 || ks } kA
Alice
Bob
May 13, 2004
ECS 235

74. Argument: Alice talking to Bob
Fourth message
If n matches first message, Alice knows it is part of this protocol exchange
Cathy generated ks because only she, Alice know kA
Enciphered part belongs to exchange as r1 matches r1 in encrypted part of first message
May 13, 2004
ECS 235

75. Argument: Bob talking to Alice
Third message
If n matches second message, Bob knows it is part of this protocol exchange
Cathy generated ks because only she, Bob know kB
Enciphered part belongs to exchange as r2 matches r2 in encrypted part of second message
May 13, 2004
ECS 235

76. Replay Attack Eve acquires old ks, message in third step
n || { r1 || ks } kA || { r2 || ks } kB
Eve forwards appropriate part to Alice
Alice has no ongoing key exchange with Bob: n matches nothing, so is rejected
Alice has ongoing key exchange with Bob: n does not match, so is again rejected
If replay is for the current key exchange, and Eve sent the relevant part before Bob did, Eve could simply listen to traffic; no replay involved
May 13, 2004
ECS 235

77. Kerberos Authentication system Ticket Authenticator
Based on Needham-Schroeder with Denning-Sacco modification
Central server plays role of trusted third party (“Cathy”)
Ticket
Issuer vouches for identity of requester of service
Authenticator
Identifies sender
May 13, 2004
ECS 235

78. Idea User u authenticates to Kerberos server
Obtains ticket Tu,TGS for ticket granting service (TGS)
User u wants to use service s:
User sends authenticator Au, ticket Tu,TGS to TGS asking for ticket for service
TGS sends ticket Tu,s to user
User sends Au, Tu,s to server as request to use s
Details follow
May 13, 2004
ECS 235

79. Tu,s = s || { u || u’s address || valid time || ku,s } ks
Ticket
Credential saying issuer has identified ticket requester
Example ticket issued to user u for service s
Tu,s = s || { u || u’s address || valid time || ku,s } ks
where:
ku,s is session key for user and service
Valid time is interval for which ticket valid
u’s address may be IP address or something else
Note: more fields, but not relevant here
May 13, 2004
ECS 235

80. Au,s = { u || generation time || kt } ku,s
Authenticator
Credential containing identity of sender of ticket
Used to confirm sender is entity to which ticket was issued
Example: authenticator user u generates for service s
Au,s = { u || generation time || kt } ku,s
where:
kt is alternate session key
Generation time is when authenticator generated
Note: more fields, not relevant here
May 13, 2004
ECS 235

81. Protocol user || TGS user Cathy { ku,TGS } ku || Tu,TGS Cathy user
service || Au,TGS || Tu,TGS
user
TGS
user || { ku,s } ku,TGS || Tu,s
user
TGS
Au,s || Tu,s
user
service
{ t + 1 } ku,s
user
service
May 13, 2004
ECS 235

82. Analysis First two steps get user ticket to use TGS
User u can obtain session key only if u knows key shared with Cathy
Next four steps show how u gets and uses ticket for service s
Service s validates request by checking sender (using Au,s) is same as entity ticket issued to
Step 6 optional; used when u requests confirmation
May 13, 2004
ECS 235

83. Problems Relies on synchronized clocks Tickets have some fixed fields
If not synchronized and old tickets, authenticators not cached, replay is possible
Tickets have some fixed fields
Dictionary attacks possible
Kerberos 4 session keys weak (had much less than 56 bits of randomness); researchers at Purdue found them from tickets in minutes
May 13, 2004
ECS 235

84. Public Key Key Exchange
Here interchange keys known
eA, eB Alice and Bob’s public keys known to all
dA, dB Alice and Bob’s private keys known only to owner
Simple protocol
ks is desired session key
{ ks } eB
Alice
Bob
May 13, 2004
ECS 235

85. Problem and Solution Vulnerable to forgery or replay
Because eB known to anyone, Bob has no assurance that Alice sent message
Simple fix uses Alice’s private key
ks is desired session key
{ { ks } dA } eB
Alice
Bob
May 13, 2004
ECS 235

86. Notes Can include message enciphered with ks
Assumes Bob has Alice’s public key, and vice versa
If not, each must get it from public server
If keys not bound to identity of owner, attacker Eve can launch a man-in-the-middle attack (next slide; Cathy is public server providing public keys)
Solution to this (binding identity to keys) discussed later as public key infrastructure (PKI)
May 13, 2004
ECS 235

87. Man-in-the-Middle Attack
send Bob’s public key
Eve intercepts request
Alice
Cathy
send Bob’s public key
Eve
Cathy eB
Eve
Cathy eE
Alice
Eve
{ ks } eE
Eve intercepts message
Alice
Bob
{ ks } eB
Eve
Bob
May 13, 2004
ECS 235

88. Key Generation Goal: generate difficult to guess keys
Problem statement: given a set of K potential keys, choose one randomly
Equivalent to selecting a random number between 0 and K–1 inclusive
Why is this hard: generating random numbers
Actually, numbers are usually pseudo-random, that is, generated by an algorithm
May 13, 2004
ECS 235

89. What is “Random”?
Sequence of cryptographically random numbers: a sequence of numbers n1, n2, … such that, for any integer k > 0, an observer cannot predict nk even if all of n1, …, nk–1 are known
Best: physical source of randomness
Random pulses
Electromagnetic phenomena
Characteristics of computing environment such as disk latency
Ambient background noise
May 13, 2004
ECS 235

90. What is “Pseudorandom”?
Sequence of cryptographically pseudorandom numbers: sequence of numbers intended to simulate a sequence of cryptographically random numbers but generated by an algorithm
Very difficult to do this well
Linear congruential generators [nk = (ank–1 + b) mod n] broken
Polynomial congruential generators [nk = (ajnk–1j + … + a1nk–1 a0) mod n] broken too
Here, “broken” means next number in sequence can be determined
May 13, 2004
ECS 235

91. Best Pseudorandom Numbers
Strong mixing function: function of 2 or more inputs with each bit of output depending on some nonlinear function of all input bits
Examples: DES, MD5, SHA-1
Use on UNIX-based systems:
(date; ps gaux) | md5
where “ps gaux” lists all information about all processes on system
May 13, 2004
ECS 235

92. Cryptographic Key Infrastructure
Goal: bind identity to key
Classical: not possible as all keys are shared
Use protocols to agree on a shared key (see earlier)
Public key: bind identity to public key
Crucial as people will use key to communicate with principal whose identity is bound to key
Erroneous binding means no secrecy between principals
Assume principal identified by an acceptable name
May 13, 2004
ECS 235

93. Certificates Create token (message) containing
Identity of principal (here, Alice)
Corresponding public key
Timestamp (when issued)
Other information (perhaps identity of signer)
signed by trusted authority (here, Cathy)
CA = { eA || Alice || T } dC
May 13, 2004
ECS 235

94. Use Bob gets Alice’s certificate
If he knows Cathy’s public key, he can decipher the certificate
When was certificate issued?
Is the principal Alice?
Now Bob has Alice’s public key
Problem: Bob needs Cathy’s public key to validate certificate
Problem pushed “up” a level
Two approaches: Merkle’s tree, signature chains
May 13, 2004
ECS 235

95. Merkle’s Tree Scheme h(1,4) h(1,2) h(3,4) h(1,1) h(2,2) h(3,3) h(4,4)
Keep certificates in a file
Changing any certificate changes the file
Use crypto hash functions to detect this
Define hashes recursively
h is hash function
Ci is certificate i
Hash of file (h(1,4) in example) known to all
h(1,4)
h(1,2) h(3,4)
h(1,1) h(2,2) h(3,3) h(4,4)
C C C C4
May 13, 2004
ECS 235

96. Validation h(1,4) h(1,2) h(3,4) h(1,1) h(2,2) h(3,3) h(4,4)
To validate C1:
Compute h(1, 1)
Obtain h(2, 2)
Compute h(1, 2)
Obtain h(3, 4)
Compute h(1,4)
Compare to known h(1, 4)
Need to know hashes of children of nodes on path that are not computed
h(1,4)
h(1,2) h(3,4)
h(1,1) h(2,2) h(3,3) h(4,4)
C C C C4
May 13, 2004
ECS 235

97. Details f: DDD maps bit strings to bit strings
h: NND maps integers to bit strings
if i ≥ j, h(i, j) = f(Ci, Cj)
if i < j,
h(i, j) = f(h(i, (i+j)/2), h((i+j)/2+1, j))
May 13, 2004
ECS 235

98. Problem File must be available for validation
Otherwise, can’t recompute hash at root of tree
Intermediate hashes would do
Not practical in most circumstances
Too many certificates and users
Users and certificates distributed over widely separated systems
May 13, 2004
ECS 235

99. Certificate Signature Chains
Create certificate
Generate hash of certificate
Encipher hash with issuer’s private key
Validate
Obtain issuer’s public key
Decipher enciphered hash
Recompute hash from certificate and compare
Problem: getting issuer’s public key
May 13, 2004
ECS 235

100. X.509 Chains Some certificate components in X.509v3: Version
Serial number
Signature algorithm identifier: hash algorithm
Issuer’s name; uniquely identifies issuer
Interval of validity
Subject’s name; uniquely identifies subject
Subject’s public key
Signature: enciphered hash
May 13, 2004
ECS 235

101. X.509 Certificate Validation
Obtain issuer’s public key
The one for the particular signature algorithm
Decipher signature
Gives hash of certificate
Recompute hash from certificate and compare
If they differ, there’s a problem
Check interval of validity
This confirms that certificate is current
May 13, 2004
ECS 235

102. Issuers Certification Authority (CA): entity that issues certificates
Multiple issuers pose validation problem
Alice’s CA is Cathy; Bob’s CA is Don; how can Alice validate Bob’s certificate?
Have Cathy and Don cross-certify
Each issues certificate for the other
May 13, 2004
ECS 235

103. Validation and Cross-Certifying
Certificates:
Cathy<<Alice>>
Dan<<Bob>
Cathy<<Dan>>
Dan<<Cathy>>
Alice validates Bob’s certificate
Alice obtains Cathy<<Dan>>
Alice uses (known) public key of Cathy to validate Cathy<<Dan>>
Alice uses Cathy<<Dan>> to validate Dan<<Bob>>
May 13, 2004
ECS 235

104. PGP Chains OpenPGP certificates structured into packets
One public key packet
Zero or more signature packets
Public key packet:
Version (3 or 4; 3 compatible with all versions of PGP, 4 not compatible with older versions of PGP)
Creation time
Validity period (not present in version 3)
Public key algorithm, associated parameters
Public key
May 13, 2004
ECS 235

105. OpenPGP Signature Packet
Version 3 signature packet
Version (3)
Signature type (level of trust)
Creation time (when next fields hashed)
Signer’s key identifier (identifies key to encipher hash)
Public key algorithm (used to encipher hash)
Hash algorithm
Part of signed hash (used for quick check)
Signature (enciphered hash)
Version 4 packet more complex
May 13, 2004
ECS 235

106. Signing Single certificate may have multiple signatures
Notion of “trust” embedded in each signature
Range from “untrusted” to “ultimate trust”
Signer defines meaning of trust level (no standards!)
All version 4 keys signed by subject
Called “self-signing”
May 13, 2004
ECS 235

107. Validating Certificates
Arrows show signatures
Self signatures not shown
Alice needs to validate Bob’s OpenPGP cert
Does not know Fred, Giselle, or Ellen
Alice gets Giselle’s cert
Knows Henry slightly, but his signature is at “casual” level of trust
Alice gets Ellen’s cert
Knows Jack, so uses his cert to validate Ellen’s, then hers to validate Bob’s
Jack
Henry
Ellen
Irene
Giselle
Fred
Bob
May 13, 2004
ECS 235

108. Storing Keys
Multi-user or networked systems: attackers may defeat access control mechanisms
Encipher file containing key
Attacker can monitor keystrokes to decipher files
Key will be resident in memory that attacker may be able to read
Use physical devices like “smart card”
Key never enters system
Card can be stolen, so have 2 devices combine bits to make single key
May 13, 2004
ECS 235

109. Key Escrow
Key escrow system allows authorized third party to recover key
Useful when keys belong to roles, such as system operator, rather than individuals
Business: recovery of backup keys
Law enforcement: recovery of keys that authorized parties require access to
Goal: provide this without weakening cryptosystem
Very controversial
May 13, 2004
ECS 235

110. Desirable Properties
Escrow system should not depend on encipherment algorithm
Privacy protection mechanisms must work from end to end and be part of user interface
Requirements must map to key exchange protocol
System supporting key escrow must require all parties to authenticate themselves
If message to be observable for limited time, key escrow system must ensure keys valid for that period of time only
May 13, 2004
ECS 235

111. Components User security component Key escrow component
Does the encipherment, decipherment
Supports the key escrow component
Key escrow component
Manages storage, use of data recovery keys
Data recovery component
Does key recovery
May 13, 2004
ECS 235

112. Example: EES, Clipper Chip
Escrow Encryption Standard
Set of interlocking components
Designed to balance need for law enforcement access to enciphered traffic with citizens’ right to privacy
Clipper chip prepares per-message escrow information
Each chip numbered uniquely by UID
Special facility programs chip
Key Escrow Decrypt Processor (KEDP)
Available to agencies authorized to read messages
May 13, 2004
ECS 235

113. User Security Component
Unique device key kunique
Nonunique family key kfamily
Cipher is Skipjack
Classical cipher: 80 bit key, 64 bit input, output blocks
Generates Law Enforcement Access Field (LEAF) of 128 bits:
{ UID || { ksession } kunique || hash } kfamily
hash: 16 bit authenticator from session key and initialization vector
May 13, 2004
ECS 235