Authentication

S.R. Shinde
 Authentication
Prove continuity in relationship
– Basis of trust
– Identification Who you are
(biometrics)

Physical authentication:
where you are
What you have
(tokens)
What you know
Password: snoopy1
Mother’s maiden name: jones
Pets name: snoopy S.R.Shinde 2
 Network Authentication

• Password
• One-time Passwords (ex. tokens)
• Network address
– Caller-id - credit card
– IP address
– MAC address – banks
• Cryptographic protocols

S.R.Shinde 3
 Concerns

• Impersonation
• Malicious insiders
• Eavesdropping
– Keyboard sniffers
– Shoulder-surfing
– Network sniffers
– Trojan horses

S.R.Shinde 4
 Mutual-Way Authentication

• Authentication often needed in both

directions
• Server trusting user is not only concern
– User must trust server
– Ex. User accessing online bank account
• Variety of “solutions” in user applications

S.R.Shinde 5
 Password-based Authentication
• Proof by sharing
• Doesn’t prevent insider attacks (system admin)
• What is an appropriate password
– length? snoopy, snoopy1, snoopy12
– reusable ? snoppy1, snoopy2, …. snoopy10, snoopy1
– timeframe?
• How to do initial password distribution? lastname123, employee#
• Simple approach, works with humans
… until user has too many to remember
– reuse across systems
– Variations of something common: dog’s name
– post-it on monitor
– inconvenient to update, varying rules on what is appropriately complex,
how often to change
snoopy1, Snoopy1, snoopy-1

S.R.Shinde 6
 Password Guessing
• Online
– Limited tries, exponential delays, alarm
– But attacker can temporarily disable a user’s account – ex. 3
tries and account locked until user calls help desk
• Offline: “dictionary” attack
– Must capture password file
– Try "obvious" passwords: snoopy, snoopy1, 1snoopy
– Significant dates, easy patterns, personal information
– While most systems disallow “dictionary words”, complexity
rules still give information – know need a digit, punctuation
character …
Snoopy-12

S.R.Shinde 7
 Passwords as Keys

• Directly as the key

• Convert to secret key
– Transient, one-way transformation (hash)
– Increase work of attacker
• Seed to pseudo-random number generator

S.R.Shinde 8
 One-Time Passwords

• List of passwords used once only

• Need to re-initialize periodically

S.R.Shinde 9
 Lamport’s Hash
• One-time passwords
• Server stores n, hashn(password)
• User sends x = hashn-1(password)
• Server computes hash(x), if = stored value, replaces stored value with n-1 ,
x

• Safe from eavesdropping, server compromise not a problem for user

• No public key cryptography
• Authentication not mutual
• Add salt to password before hashing
– In case Alice uses same password on multiple systems
– Salt must be stored on Alice’s system
– Server uses hashn(password | salt)

S.R.Shinde 10
 OTP Generators (Tokens)
• Examples
– RSA
– VASCO Digipass
• Use a block cipher
– Repeatedly encrypt
– Continuously update every x seconds
– Update each time user presses button
• Some work in both directions
– Customer enters OTP
– Server returns OTP, customer (manually) compares it to
value on token

S.R.Shinde 11
 Tokens - Issues
• Help desk required
– Synchronization not perfect
– Premature battery death
• Cost
– $15-$25
– banks with million customers
• User still needs pin (something you know + something you
have)
• “Necklace of Tokens” issue
– Only recently integrated with cell phones
– Still rare to have multiple tokens on single device
• Non-standard algorithms
– OATH effort

S.R.Shinde 12
 KDC
• Can impersonate any node
• Single point of failure
• Potential bottleneck

S.R.Shinde 13
 Certificate Authority
• Central point for certificates
• Signs cert for Alice containing her public key
• Others need only CA’s public key
• Revocation?
– Real time with online KDC
– Offline CA –expiration date, certificate revocation
list

S.R.Shinde 14
 Security Handshakes

• Considerations when creating protocols

– Attacks/Information leakage
– One-way
– Mutual Authentication

S.R.Shinde 15
 One-way Challenge-Response
Alice I’m Alice Bob

challenge R
K = shared key
f(K,R)

f:
– encryption function – Bob just decrypts and verifies time in within allowed
skew
– hash – Bob needs to hash all times in allowable interval or Alice sends time

Problems?
– Authentication not mutual
– Connection hijacking after authentication – attacker spoofs Alice or Bob’s
source address and send packets if conversation not encrypted
– Off-line password/key attack – depends on length of K
– Compromise of database/disk if K is stored, or temporary memory access
S.R.Shinde 16
 One-Way using Timestamp
Alice I’m Alice, f(K,timestamp) Bob

• Problems?
– Impersonate Alice if intercept and send message – race condition
– Keep list of used time stamps to prevent quick replay, but if use same K with
multiple servers, could send message to another server and impersonate Alice
– Clock skew/synchronization

S.R.Shinde 17
 One-way Using Public Key
Alice I’m Alice Bob

R Bob decrypts with Alice’s

public key and verifies R was
[R]Apriv returned.

Alice I’m Alice Bob

Alice proves to Bob she [R]Apub

has her private key by
returning R R

[R]Ax = R signed with Alice’s x

key, where x is private (priv) or
S.R.Shinde public (pub) key 18
 One-way Problems
• First case:
– Can send anything to Alice as R and get Alice to
sign it
• Second case:
– Intercepted an encrypted message for Alice, send
it and get Alice to decrypt it

S.R.Shinde 19
Mutual Authentication

S.R.Shinde 20
Mutual Authentication with Secret Key

Alice I’m Alice Bob

R1

f(K,R1)

R2

f(K,R2)

S.R.Shinde 21
 Mutual Authentication with Secret Key

More efficient version:

Alice I’m Alice, R2 Bob

R1, f(K,R2)
f(K,R1)

S.R.Shinde 22
 Mutual Authentication with Secret Key
Reflection attack:

Trudy I’m Alice, R2 Bob

Doesn’t R1, f(K,R2)

know K so
can’t send
f(K,R1)

Trudy I’m Alice, R1 Bob

Now use f(K,R1)

in above attempt R3, f(K,R1)

Solutions:
• Separate keys for each direction
• Requirements on R values: odd in one direction, even in the
other, concatenate with senders’ name
S.R.Shinde 23
 Password/Key Guessing
• Also note, Trudy can get Bob to encrypt a value (or a several
of values) and then try an offline attack to guess K
• Have Bob return R1 value for Alice to encrypt

Alice I’m Alice Bob

R1

R2, f(K,R1)
f(K,R2)

Now Bob would have to reuse R1 in order for

Trudy, S.R.Shinde
who eavesdrops, to be able to use f(K,R1) 24
 Timestamps

Alice I’m Alice, f(K,timestamp) Bob

f(K,timestamp+1)

• Same issues as before plus clock skew

• Any modification to timestamp will work

S.R.Shinde 25
 Mutual Authentication with Public Keys

Alice I’m Alice, [R2]Bpub Bob

[R1]Apub, R2

R1

• how to obtains/store/validate Bob’s public key

S.R.Shinde 26
 Session Key
• Once authentication occurs, want to encrypt data
exchanged
• Session key
• If key to one session obtained, can’t decrypt all
sessions
• Don’t want known/easy to derive relationship among
session keys

S.R.Shinde 27
 Centralized Authentication

• Needham-Schroeder

S.R.Shinde 28
 Needham-Schroeder
Alice KDC Bob
N1, Alice wants to talk to Bob

EKa(N1, "Bob", Kab, ticket)

N1 authenticates KDC to Alice
ticket = EKb(Kab, "Alice")

EKab(N2), ticket Bob decrypts ticket

to get Kab
EKab(N2 - 1, N3)

EKab(N3 - 1)

Nonces used to verify

each end has Kab
• N1, N2, N3 are nonces ("number used once")

S.R.Shinde 29
 Expanded Needham-Schroeder
• Issue - ticket doesn’t expire
• If Trudy obtains Alice’s key and ticket, Trudy can connect to Bob even if
Alice changes key.

Alice Bob
I want to talk to you

Ekb(Nb)

N1, Alice wants to talk to Bob, Ekb(Nb)

Nb is unique per
EKa(N1, "Bob", Kab, ticket) KDC session so can’t
ticket = EKb(Kab, "Alice", Ekb(Nb)) reuse ticket

EKab(N2), ticket

EKab(N2 - 1, N3)

EKab(N3 - 1) S.R.Shinde 30
 Needham-Schroeder
• Reflection attack in last steps if ECB mode
(and nonce size = block size)
Trudy->Bob: EKab(N2), ticket Trudy doesn’t have Kab
to obtain N4, needs N4-
Bob->Trudy: EKab(N2 - 1, N4) 1 in next step, so get
Bob to encrypt N4-1
Extract 1st block of
Trudy->Bob: EKab(N4), ticket ciphertext
Bob->Trudy: EKab(N4 - 1, N5)
Extract EKab(N4 - 1) and use in response of first
run

S.R.Shinde 31
 Kerberos
• Based on Needham-Schroeder
• Uses time and includes ticket expiration

S.R.Shinde 32
 Nonces
• Random number
– 128-bit value negligible chance of being repeated
• Timestamp
– Synchronization
– Predictable
• Sequence number
– Maintain state
– Predictable?

S.R.Shinde 33
 Random Numbers
• Be careful with seed
• Size
• Easily known value: timestamp
• Divulging seed – don’t use some value
included unencrypted in message

S.R.Shinde 34
 Performance
• Number of messages exchanged
• Number of operations
– using secret key algorithm
– using public key algorithm
– using hash
• And number of bytes involved

S.R.Shinde 35
 Checklist
• Eavesdropping
• Initiation of conversation/partial conversations
• Impersonation by accepting a connection
• Access to disk/database at either end
• Man-in-middle

S.R.Shinde 36
 Overview
• An essential part of Windows servers
• Authentication infrastructure
– Designed to authenticate users to servers
– Users must use their password as their initial key
and must not be forced to retype it constantly
• Based on Needham-Schroeder, with
timestamps to limit key lifetime

S.R.Shinde 37
 Kerberos
• trusted key server system from MIT
• provides centralised private-key third-party
authentication in a distributed network
– allows users access to services distributed through
network
– without needing to trust all workstations
– rather all trust a central authentication server
• two versions in use: 4 & 5

S.R.Shinde 38
 Kerberos Requirements
• first published report identified its
requirements as:
– security
– reliability
– transparency
– scalability
• implemented using an authentication protocol
based on Needham-Schroeder

S.R.Shinde 39
 Kerberos 4 Overview
• a basic third-party authentication scheme
• have an Authentication Server (AS)
– users initially negotiate with AS to identify self
– AS provides a non-corruptible authentication
credential (ticket granting ticket TGT)
• have a Ticket Granting server (TGS)
– users subsequently request access to other
services from TGS on basis of users TGT

S.R.Shinde 40
Kerberos 4 Overview

S.R.Shinde 41
 Kerberos Realms
• a Kerberos environment consists of:
– a Kerberos server
– a number of clients, all registered with server
– application servers, sharing keys with server
• this is termed a realm
– typically a single administrative domain
• if have multiple realms, their Kerberos servers
must share keys and trust

S.R.Shinde 42
 Kerberos Version 5
• developed in mid 1990’s
• provides improvements over v4
– addresses environmental shortcomings
• encryption alg, network protocol, byte order, ticket
lifetime, authentication forwarding, interrealm auth
– and technical deficiencies
• double encryption, non-std mode of use, session keys,
password attacks
• specified as Internet standard RFC 1510

S.R.Shinde 43
 Delegation
• Delegation of rights
– Alice wants Bob to access resource X on behalf of Alice for
time t.
• Example: Alice logs into host Bob then wants to log into host X
from Bob
– Alice can request ticket with Bob’s address or a list of
addresses
– Ticket can include application specific data – not used by
Kerberos but used by host
• Can set to not allow delegation

S.R.Shinde 44
 Ticket Lifetime
• V4: 21 hours max
• V5: up to Dec. 31, 9999
• Lifetime in seconds
• Not revocable – be careful
• Time ticket granted, start time and stop time
• Renew until – instead of long lifetime, give option to keep
renewing
– If stop using/needing ticket, won’t remain open
• Postdating
• Grant ticket to run some process in future
– Batch job at end of week but requested ticket at beginning of week

S.R.Shinde 45
 Key Version
• Suppose Alice has ticket to Bob
• Bob changes his key with KDC
• KDC keeps versions both versions of Bob’s key
(key, version)
• Alice’s ticket keeps working until it expires
• Any other renewable or post-dated ticket will
work with old key

S.R.Shinde 46
 Master Keys and Realms
• Master keys – key between entity (such as Alice) and
KDC
• Alice registered to realms R1, R2
– Uses same password
• Hash password with realm name to get master key
• If attacker gets Alice’s password, still can compute
both master keys
• But R1 and R2 don’t have the other’s master key for
Alice. If attacker breaks into one, won’t get both keys.

S.R.Shinde 47
 Password Guessing
• V4: anyone can send ticket request to KDC

Alice wants to talk to Bob

Trudy KDC

• V5: include encrypted timestamp

Alice wants to talk to Bob,

EKa(timestamp)
Alice KDC

S.R.Shinde 48
 Password-Guessing
• Kerberos tickets have verifiable plaintext
• An attacker can run password-guessing
programs on intercepted ticket-granting
tickets (Merritt and Bellovin invented EKE
while studying this problem with Kerberos.)
• Kerberos uses passphrases instead of
passwords
• Does this make guessing harder? Not sure

S.R.Shinde 49
 Password Guessing
• On many Kerberos systems, anyone can ask the KDC
for a TGT
• There’s no need to eavesdrop to get them — you can
get all the TGTs you want over the Internet.
• Solution: preauthentication
• The initial request includes a timestamp encrypted
with Kc
• It’s still verifiable plaintext, but collecting TGTs
becomes harder again

S.R.Shinde 50
 Multiple Sessions – Added Security
• Alice opens two sessions to Bob
• Don’t want Trudy swapping messages
between sessions
• Alice specifies different session key to use for
each

S.R.Shinde 51
 Hash function
• A hash function is a reproducible method of
turning some kind of data into a (relatively)
small number that may serve as a digital
"fingerprint" of the data.
• The algorithm "chops and mixes" (for instance,
substitutes or transposes) the data to create
such fingerprints.

S.R.Shinde 52
 Secure Hash Algorithm
• The SHA hash functions are five cryptographic hash
functions - SHA-1, SHA-224, SHA-256, SHA-384, SHA-
512.
• Hash algorithms compute a fixed-length digital
representation (known as a message digest) of an
input data sequence (the message) of any length.
• Any change to a message will, with a very high
probability, result in a different message digest.

S.R.Shinde 53
 SHA

S.R.Shinde 54
 Cryptanalysis of SHA-0
• At CRYPTO 98, two French researchers, Florent Chabaud and Antoine Joux, presented an
attack on SHA-0 (Chabaud and Joux, 1998): collisions can be found with complexity 2^61,
fewer than the 2^80 for an ideal hash function of the same size.

• In 2004, Biham and Chen found near-collisions for SHA-0 — two messages that hash to nearly
the same value; in this case, 142 out of the 160 bits are equal. They also found full collisions
of SHA-0 reduced to 62 out of its 80 rounds.

• Subsequently, on 12 August 2004, a collision for the full SHA-0 algorithm was announced by
Joux, Carribault, Lemuet, and Jalby. This was done by using a generalization of the Chabaud
and Joux attack. Finding the collision had complexity 2^51 and took about 80,000 CPU hours
on a supercomputer with 256 Itanium 2 processors.

• On 17 August 2004, at the Rump Session of CRYPTO 2004, preliminary results were
announced by Wang, Feng, Lai, and Yu, about an attack on MD5, SHA-0 and other hash
functions. The complexity of their attack on SHA-0 is 2^40, significantly better than the attack
by Joux et al.
• In February 2005, an attack by Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu was announced
which could find collisions in SHA-0 in 2^39 operations.

S.R.Shinde 55
 Cryptanalysis of SHA-1
• In light of the results on SHA-0, some experts suggested that plans for the use of SHA-1 in new cryptosystems should be
reconsidered. After the CRYPTO 2004 results were published, NIST announced that they planned to phase out the use of
SHA-1 by 2010 in favor of the SHA-2 variants.

• In early 2005, Rijmen and Oswald published an attack on a reduced version of SHA-1 — 53 out of 80 rounds — which finds
collisions with a complexity of fewer than 2^80 operations.

• In February 2005, an attack by Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu was announced. The attacks can find collisions
in the full version of SHA-1, requiring fewer than 2^69 operations. (A brute-force search would require 2^80 operations.)

• The authors write: "In particular, our analysis is built upon the original differential attack on SHA0 , the near collision attack
on SHA0, the multiblock collision techniques, as well as the message modification techniques used in the collision search
attack on MD5. Breaking SHA1 would not be possible without these powerful analytical techniques.". The authors have
presented a collision for 58-round SHA-1, found with 2^33 hash operations. The paper with the full attack description was
published in August 2005 at the CRYPTO conference.

• In an interview, Yin states that, "Roughly, we exploit the following two weaknesses: One is that the file preprocessing step is
not complicated enough; another is that certain math operations in the first 20 rounds have unexpected security problems."

• On 17 August 2005, an improvement on the SHA-1 attack was announced on behalf of Xiaoyun Wang, Andrew Yao and
Frances Yao at the CRYPTO 2005 rump session, lowering the complexity required for finding a collision in SHA-1 to 2^63. On
18 December 2007 the details of this result were explained and verified by Martin Cochran.

• Christophe De Cannière and Christian Rechberger further improved the attack on SHA-1 in "Finding SHA-1 Characteristics:
General Results and Applications,"receiving the Best Paper Award at ASIACRYPT 2006. A two-block collision for 64-round
SHA-1 was presented, found using unoptimized methods with 2^35 compression function evaluations.

• As this attack requires the equivalent of about 2^35 evaluations, it is considered to be a theoretical break.To find an actual
collision, however, a massive distributed computing effort or very large parallel supercomputer such as those possessed by
the NSA would be required. To that end, a collision search for SHA-1 using the distributed computing platform BOINC is
currently being made. S.R.Shinde 56
• At the Rump Session of CRYPTO 2006, Christian Rechberger and Christophe De Cannière claimed to have discovered a
 SHA-1 algorithm
• Note: All variables are unsigned 32 bits and wrap modulo 232 when calculating

• Initialize variables:
• h0 = 0x67452301
• h1 = 0xEFCDAB89
• h2 = 0x98BADCFE
• h3 = 0x10325476
• h4 = 0xC3D2E1F0

• Pre-processing:
• append the bit '1' to the message
• append k bits '0', where k is the minimum number ≥ 0 such that the resulting message
• length (in bits) is congruent to 448 (mod 512)
• append length of message (before pre-processing), in bits, as 64-bit big-endian integer

• Process the message in successive 512-bit chunks:

• break message into 512-bit chunks
• for each chunk
• break chunk into sixteen 32-bit big-endian words w[i], 0 <= i <= 15

• Extend the sixteen 32-bit words into eighty 32-bit words:

• for i from 16 to 79
• w[i] = (w[i-3] xor w[i-8] xor w[i-14] xor w[i-16]) leftrotate 1

• Initialize hash value for this chunk:

• a = h0
• b = h1
• c = h2
• d = h3
• e = h4
• …. S.R.Shinde 57
 SHA-1 algorithm
• Main loop:
• for i from 0 to 79
• if 0 ≤ i ≤ 19 then
• f = (b and c) or ((not b) and d)
• k = 0x5A827999
• else if 20 ≤ i ≤ 39
• f = b xor c xor d
• k = 0x6ED9EBA1
• else if 40 ≤ i ≤ 59
• f = (b and c) or (b and d) or (c and d)
• k = 0x8F1BBCDC
• else if 60 ≤ i ≤ 79
• f = b xor c xor d
• k = 0xCA62C1D6

• temp = (a leftrotate 5) + f + e + k + w[i]

• e=d
• d=c
• c = b leftrotate 30
• b=a
• a = temp

• Add this chunk's hash to result so far:

• h0 = h0 + a
• h1 = h1 + b
• h2 = h2 + c
• h3 = h3 + d
• h4 = h4 + e
• Produce the final hash value (big-endian):
• S.R.Shinde
digest = hash = h0 append h1 append h2 append h3 append h4 58
 SHA-2 algorithm
• Initialize variables
• (first 32 bits of the fractional parts of the square roots of the first 8 primes 2..19):
• h0 := 0x6a09e667
• h1 := 0xbb67ae85
• h2 := 0x3c6ef372
• h3 := 0xa54ff53a
• h4 := 0x510e527f
• h5 := 0x9b05688c
• h6 := 0x1f83d9ab
• h7 := 0x5be0cd19

• Initialize table of round constants

• (first 32 bits of the fractional parts of the cube roots of the first 64 primes 2..311):
• k[0..63] :=
• 0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, 0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5,
• 0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3, 0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174,
• 0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc, 0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da,
• 0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7, 0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967,
• 0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13, 0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,
• 0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, 0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070,
• 0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5, 0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3,
• 0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208, 0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2

• Pre-processing:
• append the bit '1' to the message
• append k bits '0', where k is the minimum number >= 0 such that the resulting message
• length (in bits) is congruent to 448 (mod 512)
• append length of message (before pre-processing), inS.R.Shinde
bits, as 64-bit big-endian integer 59
 SHA-2 algorithm
• Process the message in successive 512-bit chunks:
• break message into 512-bit chunks
• for each chunk
• break chunk into sixteen 32-bit big-endian words w[0..15]

• Extend the sixteen 32-bit words into sixty-four 32-bit words:

• for i from 16 to 63
• s0 := (w[i-15] rightrotate 7) xor (w[i-15] rightrotate 18) xor (w[i-15] rightshift 3)
• s1 := (w[i-2] rightrotate 17) xor (w[i-2] rightrotate 19) xor (w[i-2] rightshift 10)
• w[i] := w[i-16] + s0 + w[i-7] + s1

• Initialize hash value for this chunk:

• a := h0
• b := h1
• c := h2
• d := h3
• e := h4
• f := h5
• g := h6
• h := h7

S.R.Shinde 60
 SHA-2 algorithm
• Main loop:
• for i from 0 to 63
• s0 := (a rightrotate 2) xor (a rightrotate 13) xor (a rightrotate 22)
• maj := (a and b) xor (a and c) xor (b and c)
• t2 := s0 + maj
• s1 := (e rightrotate 6) xor (e rightrotate 11) xor (e rightrotate 25)
• ch := (e and f) xor ((not e) and g)
• t1 := h + s1 + ch + k[i] + w[i]

• h := g
• g := f
• f := e
• e := d + t1
• d := c
• c := b
• b := a
• a := t1 + t2

• Add this chunk's hash to result so far:

• h0 := h0 + a
• h1 := h1 + b
• h2 := h2 + c
• h3 := h3 + d
• h4 := h4 + e
• h5 := h5 + f
• h6 := h6 + g
• h7 := h7 + h

• Produce the final hash value (big-endian):

• digest = hash = h0 append h1 append h2 append h3 append h4 append h5 append h6 append h7
S.R.Shinde 61
 SHA-1

• One iteration within the SHA-1 compression function. A, B, C, D and E

are 32-bit words of the state; F is a nonlinear function that varies; n
denotes a left bit rotation by n places; n varies for each operation.
denotes addition modulo 2^32. Kt is a constant.

S.R.Shinde 62
SHA-2

S.R.Shinde 63
 Example hashes
• SHA1("The quick brown fox jumps over the lazy dog")
• = 2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12

• SHA1("The quick brown fox jumps over the lazy cog")

• = de9f2c7f d25e1b3a fad3e85a 0bd17d9b 100db4b3

• The hash of the zero-length message is:

• SHA1("")
• = da39a3ee 5e6b4b0d 3255bfef 95601890 afd80709

S.R.Shinde 64
 Example hashes
• SHA1("The quick brown fox jumps over the lazy dog")
• = 2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12

• SHA-256
• SHA256("The quick brown fox jumps over the lazy dog")
• = d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592

• SHA-512
• SHA512("The quick brown fox jumps over the lazy dog")
• = 07e547d9586f6a73f73fbac0435ed76951218fb7d0c8d788a309d785436bbb64
• 2e93a252a954f23912547d1e8a3b5ed6e1bfd7097821233fa0538f3db854fee6

S.R.Shinde 65
 SHA-512
• Step 1: Append padding bits
• Step 2: Append length
• Step 3: Initialize hash buffer
• Step 4: Process the message in 1024-bit (128-
word) blocks, which forms the heart of the
algorithm
• Step 5: Output the final state value as the
resulting hash
S.R.Shinde 66
SHA-512 Overview

S.R.Shinde 67
 SHA-512 Compression Function
• heart of the algorithm
• processing message in 1024-bit blocks
• consists of 80 rounds
– updating a 512-bit buffer
– using a 64-bit value Wt derived from the current
message block
– and a round constant based on cube root of first
80 prime numbers

S.R.Shinde 68
S.R.Shinde 69
SHA-512 Round Function

S.R.Shinde 70
 Function Elements
• Ch(e,f,g) = (e AND f) XOR (NOT e AND g)
• Maj(a,b,c) = (a AND b) XOR (a AND c) XOR (b AND c)
• ∑(a) = ROTR(a,28) XOR ROTR(a,34) XOR ROTR(a,39)
• ∑(e) = ROTR(e,14) XOR ROTR(e,18) XOR ROTR(e,41)
• + = addition modulo 2^64
– Kt = a 64-bit additive constant
– Wt = a 64-bit word derived from the current 512-
bit input block.

S.R.Shinde 71
SHA-512 Round Function

S.R.Shinde 72
 Keyed Hash Functions as MACs
• want a MAC based on a hash function
– because hash functions are generally faster
– code for crypto hash functions widely available
• hash includes a key along with message
• original proposal:
KeyedHash = Hash(Key|Message)
– some weaknesses were found with this
• eventually led to development of HMAC

S.R.Shinde 73
 HMAC
• specified as Internet standard RFC2104
• uses hash function on the message:
HMACK = Hash[(K+ XOR opad) ||
Hash[(K+ XOR ipad)||M)]]
• where K+ is the key padded out to size
• and opad, ipad are specified padding constants
• overhead is just 3 more hash calculations than the
message needs alone
• any hash function can be used
– eg. MD5, SHA-1, RIPEMD-160, Whirlpool

S.R.Shinde 74
HMAC Overview

S.R.Shinde 75
 X.509 Authentication Service
• part of CCITT X.500 directory service standards
– distributed servers maintaining some info database
• defines framework for authentication services
– directory may store public-key certificates
– with public key of user
– signed by certification authority
• also defines authentication protocols
• uses public-key crypto & digital signatures
– algorithms not standardised, but RSA recommended

S.R.Shinde 76
 X.509 Certificates
• issued by a Certification Authority (CA), containing:
– version (1, 2, or 3)
– serial number (unique within CA) identifying certificate
– signature algorithm identifier
– issuer X.500 name (CA)
– period of validity (from - to dates)
– subject X.500 name (name of owner)
– subject public-key info (algorithm, parameters, key)
– issuer unique identifier (v2+)
– subject unique identifier (v2+)
– extension fields (v3)
– signature (of hash of all fields in certificate)
• notation CA<<A>> denotes certificate for A signed by CA

S.R.Shinde 77
X.509 Certificates

S.R.Shinde 78
 Obtaining a Certificate
• any user with access to CA can get any
certificate from it
• only the CA can modify a certificate
• because cannot be forged, certificates can be
placed in a public directory

S.R.Shinde 79
 CA Hierarchy
• if both users share a common CA then they are
assumed to know its public key
• otherwise CA's must form a hierarchy
• use certificates linking members of hierarchy to
validate other CA's
– each CA has certificates for clients (forward) and parent
(backward)
• each client trusts parents certificates
• enable verification of any certificate from one CA by
users of all other CAs in hierarchy

S.R.Shinde 80
CA Hierarchy Use

S.R.Shinde 81
 Certificate Revocation
• certificates have a period of validity
• may need to revoke before expiry, eg:
1. user's private key is compromised
2. user is no longer certified by this CA
3. CA's certificate is compromised
• CA’s maintain list of revoked certificates
– the Certificate Revocation List (CRL)
• users should check certs with CA’s CRL

S.R.Shinde 82
 Authentication Procedures
• X.509 includes three alternative
authentication procedures:
• One-Way Authentication
• Two-Way Authentication
• Three-Way Authentication
• all use public-key signatures

S.R.Shinde 83
 One-Way Authentication
• 1 message ( A->B) used to establish
– the identity of A and that message is from A
– message was intended for B
– integrity & originality of message
• message must include timestamp, nonce, B's
identity and is signed by A

S.R.Shinde 84
 Two-Way Authentication
• 2 messages (A->B, B->A) which also
establishes in addition:
– the identity of B and that reply is from B
– that reply is intended for A
– integrity & originality of reply
• reply includes original nonce from A, also
timestamp and nonce from B

S.R.Shinde 85
 Three-Way Authentication
• 3 messages (A->B, B->A, A->B) which enables
above authentication without synchronized
clocks
• has reply from A back to B containing signed
copy of nonce from B
• means that timestamps need not be checked
or relied upon

S.R.Shinde 86
 X.509 Version 3
• has been recognised that additional
information is needed in a certificate
– email/URL, policy details, usage constraints
• rather than explicitly naming new fields
defined a general extension method
• extensions consist of:
– extension identifier
– criticality indicator
– extension value

S.R.Shinde 87
 Certificate Extensions
• key and policy information
– convey info about subject & issuer keys, plus
indicators of certificate policy
• certificate subject and issuer attributes
– support alternative names, in alternative formats
for certificate subject and/or issuer
• certificate path constraints
– allow constraints on use of certificates by other
CA’s

S.R.Shinde 88
 Access Control-Introduction
• “Access control” is where security engineering meets
computer science.
• Its function is to control which (active) subject have access
to a which (passive) object with some specific access
operation.

subject Access object

Operation

S.R.Shinde 89
 Access Control
• Discretionary Access Control (DAC)
– Access Matrix Model
– Implementation of the Access Matrix
– Vulnerabilities of the Discretionary Policies
– Additional features of DAC

S.R.Shinde 90
Discretionary Access Control
 Access to data objects (files, directories, etc.) is
permitted based on the identity of users.
 Explicit access rules that establish who can, or
cannot, execute which actions on which resources.
 Discretionary: users can be given the ability of
passing on their privileges to other users, where
granting and revocation of privileges is regulated
by an administrative policy.

S.R.Shinde 91
 Discretionary Access Control
 DAC is flexible in terms of policy
specification
 This is the form of access control widely
implemented in standard multi-user
platforms Unix, NT, Novell, etc.

S.R.Shinde 92
Discretionary Access Control
• Access control matrix
– Describes protection state precisely
– Matrix describing rights of subjects
– State transitions change elements of matrix
• State of protection system
– Describes current settings, values of system
relevant to protection

S.R.Shinde 93
 Access Control
• Discretionary Access Control
– Access Control Matrix Model
– Implementation of the Access Matrix
– Vulnerabilities of the Discretionary Policies
– Additional features of DAC

S.R.Shinde 94
 Access Control Matrix Model
• Access control matrix
– Firstly identify the objects, subjects and actions.
– Describes the protection state of a system.
– State of the system is defined by a triple (S, O, A)
• S is the set of subject,
• O is the set of objects,
• A is the access matrix
– Elements indicate the access rights that subjects
have on objects
• Entry A[s, o] of access control matrix is the privilege
of s on o

S.R.Shinde 95
 Description
objects (entities)
o1 … om s1 … sn • Subjects S = { s1,…,sn }
s1 • Objects O = { o1,…,om }
s2 • Rights R = { r1,…,rk }
subjects

• Entries A[si, oj]  R

… • A[si, oj] = { rx, …, ry } means
subject si has rights rx, …,
sn ry over object oj

S.R.Shinde 96
 Boolean Expression Evaluation
• ACM controls access to database fields
– Subjects have attributes
– Action/Operation/Verb define type of access
– Rules associated with objects, action pair
• Subject attempts to access object
– Rule for object, action evaluated, grants or denies
access

S.R.Shinde 97
 Example
• Subject Annie
– Attributes role (artist), groups (creative)
• Verb paint
– Default 0 (deny unless explicitly granted)
• Object picture
– Rule:
Annie paint picture if:
‘artist’ in subject.role and
‘creative’ in subject.groups and
time.hour ≥ 0 and time.hour < 5

S.R.Shinde 98
 ACM at 3AM and 10AM

At 3AM, time condition At 10AM, time condition

met; ACM is: not met; ACM is:

… picture … … picture …
… annie …

… annie …
paint

S.R.Shinde 99
 Access Controlled by History
Name Position Age Salary
• Statistical databases need to
– answer queries on groups Alice Teacher 45 40K

– prevent revelation of individual Bob Aide 20 20K

records
Cathy Principal 37 60K
• Query-set-overlap control
Dilbert Teacher 50 50K
– Prevent an attacker to obtain
individual piece of information usingEve Teacher 33 50K
a set of queries C
– A parameter r (=2) is used to
determine if a query should be
answered

S.R.Shinde 100
 Access Controlled by History
• Query 1: Name Position Age Salary
Celia Teacher 45 40K
– sum_salary(position = teacher)
Leonard Teacher 50 50K
– Answer: 140K Matt Teacher 33 50K
• Query 2:
– sum_salary(age > 40 & position =
teacher) Name Position Age Salary
– Should not be answered as Matt’s Celia Teacher 45 40K
salary can be deduced Leonard Teacher 50 50K

• Can be represented as an ACM

S.R.Shinde 101
 Solution: Query Set Overlap Control
(Dobkin, Jones & Lipton ’79)
• Query valid if intersection of query coverage
and each previous query < r
• Can represent as access control matrix
– Subjects: entities issuing queries
– Objects: Powerset of records
– Os(i) : objects referenced by s in queries 1..i
– M[s,o] = read iff  q o  r
qO ( i  1)
s

S.R.Shinde 102
  q o  r
M[s,o] = read iff qO ( i  1)
s

• Query 1: O1 = {Celia, Leonard, Matt} so the query can

be answered. Hence
– M[asker, Celia] = {read}
– M[asker, Leonard] = {read}
– M[asker, Matt] = {read}

• Query 2: O2 = {Celia, Leonard} but | O2 Ç O1 | = 2; so

the query cannot be answered
– M[asker, Celia] = 
– M[asker, Leonard] = 
S.R.Shinde 103
 Access Control
• Discretionary Access Control
– Access Matrix Model
– Implementation of the Access Control Matrix
– Vulnerabilities of the Discretionary Policies
– Additional features of DAC

S.R.Shinde 104
 ACM Implementation
• ACM is an abstract model
– Rights may vary depending on the object involved
• ACM is implemented primarily in three ways
– Authorization Table
– Capabilities (rows)
– Access control lists (columns)

S.R.Shinde 105
 Authorization Table
 Three columns: subjects, actions, objects
 Generally used in DBMS systems

S.R.Shinde 106
 Access Control List (ACL)
• Matrix is stored by column.
• Each object is associated with a list
• Indicate for each subject the actions that the subject can
exercise on the object

S.R.Shinde 107
 Capability List
• Matrix is stored by row
• Each user is associated with a capability list
• Indicating for each object the access that the user is allow
to exercise on the object

S.R.Shinde 108
 ACLs vs Capability List
• Immediate to check the authorization holding on
an object with ACLs. (subject?)
• Immediate to determine the privileges of a
subject with Capability lists. (object?)
• Distributed system,
– authenticate once, access various servers
– choose which one?
• Limited number of groups of users, small bit
vectors, authorization specified by owner.
– Which one?
S.R.Shinde 109
 Basic Operations in Access Control
• Grant permissions
– Inserting values in the matrix’s entries
• Revoke permissions
– Remove values from the matrix’s entries
• Check permissions
– Verifying whether the entry related to a subject s
and an object o contains a given access mode

S.R.Shinde 110
 Access Control
Discretionary Access Control
– Access Matrix Model
– State of Protection System
– Implementation of the Access Matrix
– Vulnerabilities of the Discretionary Policies
– Additional features of DAC

S.R.Shinde 111
Vulnerabilities of the Discretionary Policies

• No separation of users from subjects

• No control on the flow the information
• Malicious code, i.e., Trojan horse

S.R.Shinde 112
 Example
• Vicky, a top-level manager
• A file Market on the new products release
• John, subordinate of Vicky
• A file called “Stolen”
• An application with two hidden operations
– Read operation on file Market
– Write operation on file Stolen

S.R.Shinde 113
Example (cond)

S.R.Shinde 114
 Example (cond)

• Restriction should be enforced on the

operations that processes themselves can
execute.
• Mandatory policies provide a way to enforce
information flow control
S.R.Shindethrough the use of 115
 Access Control
• Discretionary Access Control
– Access Matrix Model
– State of Protection System
– Implementation of the Access Matrix
– Vulnerabilities of the Discretionary Policies
– Additional features of DAC

S.R.Shinde 116
 DAC – additional features and
recent trends
• Flexibility is enhanced by supporting different
kinds of permissions
– Positive vs. negative
– Strong vs. weak
– Implicit vs. explicit
– Content-based

S.R.Shinde 117
 Positive and Negative Permissions
• Positive permissions  Give access
• Negative permissions  Deny access
• Useful to specify exceptions to a given policy
and to enforce stricter control on particular
crucial data items

S.R.Shinde 118
Positive and Negative Permissions

Main Issue: Conflicts

S.R.Shinde 119
 Authorization Conflicts
• Main solutions:
– No conflicts
– Negative permissions take precedence
– Positive permissions take precedence
– Nothing take precedence
– Most specific permissions take precedence

S.R.Shinde 120
 Weak and Strong Permissions
• Strong permissions cannot be overwritten
• Weak permissions can be overwritten by
strong and weak permissions

S.R.Shinde 121
 Implicit and Explicit Permissions
• Some models support implicit permissions
• Implicit permissions can be derived:
– by a set of propagation rules exploiting the
subject, object, and privilege hierarchies
– by a set of user-defined derivation rules

S.R.Shinde 122
 Derivation Rules: Example

• Ann can read file F1 from a table if Bob

has an explicit denial for this access
• Tom has on file F2 all the permissions that
Bob has
• Derivation rules are a way to concisely
express a set of security requirements

S.R.Shinde 123
 Derivation Rules

• Derivation rules are often expressed

according to logic programming
• Several research efforts have been
carried out to compare the expressive
power of such languages
• We need languages based on SQL and/or
XML

S.R.Shinde 124
 Content-based Permissions
• Content-based access control conditions the
access to a given object based on its content
• This type of permissions are mainly relevant for
database systems
• As an example, in a RDBMS supporting content-
based access control it is possible to authorize a
subject to access information only of those
employees whose salary is not greater than 30K

S.R.Shinde 125
 Content-based Permissions
• Two most common approaches to enforce
content-based access control in a DBMS are
done:
– by associating a predicate (or a Boolean
combination of predicates) with the permission
– by defining a view which selects the objects
whose content satisfies a given condition, and
then granting the permission on the view
instead of on the basic objects

S.R.Shinde 126
 DAC models - DBMS vs OS
• Increased number of objects to be protected
• Different granularity levels (relations, tuples,
single attributes)
• Protection of logical structures (relations, views)
instead of real resources (files)
• Different architectural levels with different
protection requirements
• Relevance not only of data physical
representation, but also of their semantics

S.R.Shinde 127
Access Control -- RBAC
 RBAC
• Many organizations base access control decisions on “the roles that
individual users take on as part of the organization”.
• They prefer to centrally control and maintain access rights that reflect the
organization’s protection guidelines.
• With RBAC, role-permission relationships can be predefined, which makes
it simple to assign users to the predefined roles.
• The combination of users and permissions tend to change over time, the
permissions associated with a role are more stable.
• RBAC concept supports three well-known security principles:
– Least privilege
– Separation of duties
– Data abstraction

S.R.Shinde 129
Role Based Access Control (RBAC)
• Access control in
organizations is Roles Hierarchies
based on “roles
that individual
users take on as
part of the
organization” User Role
Assignment
Role Permission
Assignment
Users Roles
• A role is “is a Permissions

collection of
permissions”

Constraints

S.R.Shinde 130
 RBAC
• Access depends on role/function, not identity
– Example: Allison is bookkeeper for Math Dept.
She has access to financial records. If she leaves
and Betty is hired as the new bookkeeper, Betty
now has access to those records. The role of
“bookkeeper” dictates access, not the identity of
the individual.

S.R.Shinde 131
 Advantages of RBAC
• Allows Efficient Security Management
– Administrative roles, Role hierarchy
• Principle of least privilege allows minimizing damage
• Separation of Duties constraints to prevent fraud
• Allows grouping of objects
• Policy-neutral - Provides generality
• Encompasses DAC and MAC policies

S.R.Shinde 132
 RBAC
Users Permission Users Permissions
Manager
u1 o1 u1 o1

Senior Senior
Administrator Engineer u2 Role o2 u2 o2
r

Administrator Engineer
un om un om

Employee n+m n m
assignments assignments
(a) (b)

S.R.Shinde 133
 RBAC (cont’d)
• Is RBAC a discretionary or mandatory access control?
– RBAC is policy neutral; however individual RBAC configurations can
support a mandatory policy, while others can support a discretionary
policy.
• Role Hierarcies
• Role Administration
Project Supervisor

Test engineer Programmer

Project Member
S.R.Shinde 134
 RBAC (NIST Standard)

UA PA
Users Roles Operations Objects

Permissions
user_sessions role_sessions
(one-to-many) (many-to-many)

Sessions

An important difference from classical models is that

Subject in other models corresponds to a Session in RBAC

S.R.Shinde 135
 Core RBAC (relations)
• Permissions = 2Operations x Objects
• UA ⊆ Users x Roles
• PA ⊆ Permissions x Roles
• assigned_users: Roles  2Users
• assigned_permissions: Roles  2Permissions
• Op(p): set of operations associated with permission p
• Ob(p): set of objects associated with permission p
• user_sessions: Users  2Sessions
• session_user: Sessions  Users
• session_roles: Sessions  2Roles
– session_roles(s) = {r | (session_user(s), r)  UA)}
• avail_session_perms: Sessions  2Permissions

S.R.Shinde 136
RBAC with General Role Hierarchy
RH
(role hierarchy)

UA PA
Users Roles Operations Objects

Permissions
user_sessions
(one-to-many) role_sessions
(many-to-many)

Sessions

S.R.Shinde 137
 RBAC with General Role Hierarchy
• authorized_users: Roles 2Users
authorized_users(r) = {u | r’ ≥ r &(r’, u)  UA)
• authorized_permissions: Roles 2Permissions
authorized_users(r) = {p | r’ ≥ r &(p, r’)  PA)
• RH  Roles x Roles is a partial order
– called the inheritance relation
– written as ≥.
(r1 ≥ r2)  authorized_users(r1) ⊆ authorized_users(r2) &
authorized_permisssions(r2) ⊆ authorized_permisssions(r1)

S.R.Shinde 138
 Example
pe
x,10
py

e
p8x, e
p9y
Manager
pxe, 5py

Senior e
p3x, e
p4y pp Senior
Administrator Engineer
e
p6x, e
p7y
po
pa, pb e
p1x, e
p2y
Administrator Engineer

Employee pm, pn
px, py

p1, p2 authorized_users(Employee)?
authorized_users(Administrator)?

authorized_permissions(Employee)?
authorized_permissions(Administrator)?
S.R.Shinde 139
 Constrained RBAC
RH
Static (role hierarchy)
Separation
of Duty

UA PA
Users Roles Operations Objects

Permissions
user_sessions
(one-to-many) Dynamic
Separation
of Duty
Sessions

S.R.Shinde 140
 Separation of Duties
 No user should be given enough privileges
to misuse the system on their own.
 Statically: defining the conflicting roles
 Dynamically: Enforcing the control at
access time

S.R.Shinde 141
RBAC’s Benefits

S.R.Shinde 142
 Cost Benefits
• Saves about 7.01 minutes per employee, per year in
administrative functions
– Average IT admin salary - $59.27 per hour
– The annual cost saving is:
• $6,924/1000; $692,471/100,000
• Reduced Employee downtime
– if new transitioning employees receive their system privileges
faster, their productivity is increased
– 26.4 hours for non-RBAC; 14.7 hours for RBAC
– For average employee wage of $39.29/hour, the annual
productivity cost savings yielded by an RBAC system:
• $75000/1000; $7.4M/100,000

S.R.Shinde 143
 Mandatory Access Control (MAC)
 Security label
- Top-Secret, Secret, Public
 Objects: security classification
- File 1 is Secret, File 2 is Public
 Subjects: security clearances
- Brown is cleared to Secret, Black is cleared to Public
 Dominance ()
- Top-Secret  Secret  Public

Database Security - Farkas 144

 MAC
 Access rights: defined by comparing the security
classification of the requested objects with the
security clearance of the subject
 If access control rules are satisfied, access is
permitted
 Otherwise access is rejected
 Granularity of access rights!

Database Security - Farkas 145

MAC – Bell-LaPadula (BLP) Model
 Single security property: a subject S is allowed a
read access to an object O only if label(S)
dominates label(O)
 Star-property: a subject S is allowed a write access
to an object O only if label(O) dominates label(S)

No direct flow of information from

high security objects to low security objects!
Database Security - Farkas 146
 Multilevel Security
• Multilevel security  users at different security
level, see different versions of the database
• Problem: different versions need to be kept
consistent and coherent without downward
signaling channel (covert channel)

Database Security - Farkas 147

 Multilevel Relation
• Schema R(A1,C1,…,An,Cn,Tc)
– R: relation name
– Ai: attribute name
– Ci: security classes
– Tc: Tuple security classes
• Instantiation of relation: sets of tuples of the form
<a1,c1,…,an,cn,tc>
– ai: attribute value
– ci: attribute classification label
– tc: tuple classification label

Database Security - Farkas 148

 Multilevel Relation Example

SSN (SSN) Course (Course) Grade (Grade)

111-22-3333 S CSCE 786 S A TS
444-55-6666 S CSCE 567 S C TS

Top-secret user sees all data

Secret user sees Secret-View:
SSN (SSN) Course (Course) Grade (Grade)
111-22-3333 S CSCE 786 S null S
444-55-6666 S CSCE 567 S null S

Database Security
CSCE - Farkas
790 - Farkas 149
149
 Polyinstantiation
Secret user sees Secret-View:
SSN (SSN) Course (Course) Grade (Grade)
111-22-3333 S CSCE 786 S null S
444-55-6666 S CSCE 567 S null S

N is primary key
ret user wants to update Grade for 111-22-3333 from
(i.e., missing value) to F
llow update: inconsistent database, at TS level two different
tuples exist with the same primary key (see next slide)
Not allow update: downward signaling channel, update is
because of the existence of a TS value
Database Security - Farkas 150
 Polyinstantiation
Top-Secret View:

SSN (SSN) Course (Course) Grade (Grade)

111-22-3333 S CSCE 786 S A TS
111-22-3333 S CSCE 786 S F S
444-55-6666 S CSCE 567 S C TS

Database Security - Farkas 151

Thank You

S.R.Shinde 152