slide1
Download
Skip this Video
Download Presentation
CS 5950/6030 Network Security Class 10 ( F , 9/ 23 /05)

Loading in 2 Seconds...

play fullscreen
1 / 34

CS 5950/6030 Network Security Class 10 ( F , 9/ 23 /05) - PowerPoint PPT Presentation


  • 117 Views
  • Uploaded on

CS 5950/6030 Network Security Class 10 ( F , 9/ 23 /05). Leszek Lilien Department of Computer Science Western Michigan University [Using some slides courtesy of: Prof. Aaron Striegel — at U. of Notre Dame Prof. Barbara Endicott-Popovsky and Prof. Deborah Frincke — at U. Washington

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' CS 5950/6030 Network Security Class 10 ( F , 9/ 23 /05)' - bond


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

CS 5950/6030 Network SecurityClass 10 (F, 9/23/05)

Leszek Lilien

Department of Computer Science

Western Michigan University

[Using some slides courtesy of:

Prof. Aaron Striegel — at U. of Notre Dame

Prof. Barbara Endicott-Popovsky and Prof. Deborah Frincke — at U. Washington

Prof. Jussipekka Leiwo — at Vrije Universiteit (Free U.), Amsterdam, The Netherlands]

slide2

2. Cryptology

...

2F. The AES (Advanced Encryption Standard) Algorithm

2F.1. The AES Contest

2F.2. Overview of Rijndael

2F.3. Strength of AES

2F.4. Comparison of DES and AES

2G. Public Key Encryption

2G.1. Motivation for PKE

2G.2. Characteristics of PKE

2G.3. RSA Encryption

2H. The Uses of Encryption

2H.1. Cryptographic Hash Functions –PART 1

Class 9

slide3

2H.1. Cryptographic Hash Functions (1)

  • Integrity:
    • How can you be sure that a recived msg/doc was not modified by an attacker or malfunction?
    • Answer: use cryptography to ensure integrity
  • Idea:
    • Wax seals on letters in Middle Ages

— easy to see if broken

    • Cryptographic „seal” on doc/msg

— so that any change to it will be readily detected

slide4

Cryptographic Hash Functions (2)

  • A technique:

compute a hash fcn / checksum / msg digest

  • More formally:
    • Problem: How to send n-bit msg so that R can easily

verify that it is intact

    • Solution: Send a msg of n+k bits
      • n bits — original msg
      • k bits — checksum / msg digest
        • Generated based on the n bits
slide5
Cryptographic Hash Fcns (3)

Simple Parity for Error Detection (1)

  • Simple (non-cryptographic) technique: parity
    • Add a single parity bit to detect if a message is correct
    • Example 1: odd parity

Force the block of data to have an odd # of 1’s

      • Data = 1011 — n = 4
      • Sent block = 10110 — n+k = 4+1

— looked at ‘1011’, added 0 to have odd # of 1’s

      • Data = 0110
      • Sent block = 01101

— looked at ‘0110’, added 1 to have odd # of 1’s

    • Example 2: ASCII parity bit
      • ASCII has 7 bits for data, 8th bit is single parity bit
        • Either odd or even parity used

[cf. A. Striegel, U. Notre Dame]

slide6
Cryptographic Hash Fcns (4)

Simple Parity for Error Detection (2)

  • How parity enhances msg integrity?
    • Can detect error in 1 bit (or in odd # of bits)
        • e,.g, if R gets 01001, R knows it’s wrong

(S sent 01101)

    • Cannot detect error in 2 bits (or in even # of bits)
      • Bec. parity stays OK -> undetectable integrity violation
        • e.g, if R gets 01011, R knows it’s wrong

(S sent 01101)

    • Cannot repair errors either
      • E.g., R doesn’t know which bit in 01001 is wrong

[cf. A. Striegel, U. Notre Dame]

slide7
Cryptographic Hash Fcns (5)

Better Checksums against Errors & Attacks

  • There are better checksums than simple odd/even parity
    • Can detect multiple errors
    • Can even repair multiple errors
  • These checksums are to fix errors, not deal with attacks
  • For attacks need

cryptographic checksums / strong hash functions

slide8
Cryptographic Hash Fcns (6)

Strong Hash Function

  • Formal definition:

strong hash function (cryptographic checksum)

is h: A -> B such that:

    • For any x  A, h(x) is easy to compute
    • For any y  B, it is computationally infeasibleto find

inverse of y, i.e., x  Asuch that h(x) = y

    • It is computationally infeasibleto find a pair ofcolliding input values, i.e. x, x’  Asuch thatx≠ x’ and h(x) = h(x’)

Alternate (stronger) form for (3):

Given any x  A, it is computationally infeasible

to find x’  Asuch that x≠ x’ and h(x) = h(x’)

  • Due to (1) and (2), hash fcn is a one-way function

[cf. A. Striegel, U. Notre Dame, Barbara Endicott-Popovsky, U. Washington]

slide9
Cryptographic Hash Fcns (7)

Collisions & Attacks on Msg Integrity (1)

  • Note:
    • n bits of msg (x) mapped into k bits ofits checksum (y)
    • k < n => collisions mustexist
    • But it is computationally infeasible to find collisions for good hash fcns
  • Goal of a successful attack on msg integrity:
    • Change msg1 in such a way that checksum remains unchanged (so R doesn’t detect the forgery)
    • I.e., find msg2 that collides with the original msg1 w.r.t. checksum value
      • Finding msg2 is computationally infeasible(for good hash)

=> forging msg1 undetectably is computationally infeasible

[cf. A. Striegel, U. Notre Dame]

slide10
Cryptographic Hash Fcns (9)

File Checksum

  • File checksum
    • Calculated, a fcn defined on all bits of the file
    • Result encrypted and stored with the file
    • Each time file used by legitimate users, checksum recalculated, encrypted, stored with the file
  • File sent to R
    • When file received by R:
      • R decrypts checksum c1 received in the file
      • R independently calculates file checksum c2
      • If c1 = c2 => file integrity is OK
      • Otherwise – file integrity violated
slide12

2. Cryptology

...

2F. The AES (Advanced Encryption Standard) Algorithm

2F.1. The AES Contest

2F.2. Overview of Rijndael

2F.3. Strength of AES

2F.4. Comparison of DES and AES

2G. Public Key Encryption

2G.1. Motivation for PKE

2G.2. Characteristics of PKE

2G.3. RSA Encryption

2H. The Uses of Encryption

2H.1. Cryptographic Hash Functions – PART 1

2H.1. Cryptographic Hash Functions – PART 2

2H.2. Key Exchange

2H.3. Digital Signatures

2H.4. Certificates – PART 1

Class

9

Class

10

slide13
Cryptographic Hash Fcns (10)

Keyed vs. Keyless Crypto Checksum (1)

  • Keyedcrypto checksum
    • Key needed to computechecksum
    • Keyed hash fcns DES, AES
      • Use it in chaining mode:

link next msg block to value of the previous msg block

          • Example chaining: E(current block) XOR E(previous block)

=> connects block to all previous blocks

      • If file sent, file’s checksum could be the last block
        • If chaining used, file checksum (=last block) depends on all previous blocks => depends on all bits of the file
slide14
Cryptographic Hash Fcns (11)

Keyed vs. Keyless Crypto Checksum (2)

  • Keyedcrypto checksum – CONT.
    • Used for integrity + authentication
      • Integrity: checksum makes msg modification difficult
      • Authentication: only S and R know symmetric key

R: if msg integrity is OK, it must have been sent by S

slide15
Cryptographic Hash Fcns (12)

Keyed vs. Keyless Crypto Checksum (3)

  • Keylesscryptochecksum
    • No key requiredto computechecksum
    • Keyless hash functions
      • MD5/MD4: any msg  128-bit digest (hash, checksum)
      • SHA/SHS: any msg  160-bit digest
      • Other: MD2, HAVAL, Snefru, ...
    • Used for integrity (not authentication)
      • Integrity: checksum makes msg modification difficult

(with truly public key anybody can send msg, but nobody but S can easily modify this msg)

      • No authentication: n (or all) people know public key –

R can’t prove which one of them sent a given msg

[cf. A. Striegel, U. Notre Dame, Barbara Endicott-Popovsky, U. Washington]

slide16

2H.2. Key Exchange (1)

  • Motivation:
    • X and Y don’t know each other
    • X needs to send protected msg to Y
      • E.g., shopping on a web site
    • can do it if can securely exchange KE
  • This is the problem of key exchange
    • Important
    • Hard
      • Circular (chicken-’n-egg) problem?

„To establish secure session need secure channel”

      • Circle can be broken – by public key cryptography
        • Can send public key even on insecure channel
slide17

Key Exchange (2)

Deriving Symmetric Key via PKE (1)

  • Given
    • S and R / kPRIV-S, kPUB-S -- kPRIV-R, kPUB-R
  • Solution 1:
    • S determines secret key K
    • S encrypts K with kPRIV-S : C = E(kPRIV-S, K)
    • S sends C to R
    • R decrypts C to get K: D(kPUB-S, C) = K
    • S & R communicate using secret (symmetric) key K
  • BUT: Solution 1 is not good!!!
    • Question: Why?
slide18

Key Exchange (3)

Deriving Symmetric Key via PKE (2)

  • Given
    • S and R / kPRIV-S, kPUB-S -- kPRIV-R, kPUB-R
  • Solution 1:
    • S determines secret key K
    • S encrypts K with kPRIV-S: C = E(kPRIV-S, K)
    • S sends C to R
    • R decrypts C to get K: D(kPUB-S, C) = K
    • S & R communicate using secret (symmetric) key K
  • BUT: Solution 1 is not good !!!
    • Answer:

Attacker who has kPUB-S can also perform decryption!

      • The easier the more people know kPUB-S
      • Trivial if kPUB-S is truly public
slide19

Key Exchange (4)

Deriving Symmetric Key via PKE (3)

  • Solution 2:
    • S determines secret key K
    • S encrypts K with kPUB-R: C = E(kPUB-R, K)
    • S sends C to R
    • R decrypts C to get K: D(kPRIV-R, C) = K
    • S & R communicate using secret (symmetric) key K
  • Solution 2 is better
    • Only R can decode K (only R knows kPRIV-R)
  • ...but Solution 2 still is not quite good
    • Question: Why?
      • Hint: what about msg authentication?
slide20

Key Exchange (5)

Deriving Symmetric Key via PKE (4)

  • Solution 2:
    • S determines secret key K
    • S encrypts K with kPUB-R: C = E(kPUB-R , K)
    • S send C to R
    • R decrypts C to get K: D(kPRIV-R , C) = K
    • S & R communicate using secret (symmetric) key K
  • Solution 2 is better
    • Only R can decode K (only R knows kPRIV-R)
  • ...but Solution 2 still is not quite good
    • Answer:

No msg authentication

(R has no assurance that msg was sent by S

– anybody could have encoded with kPUB-R)

slide21

Key Exchange (6)

Deriving Symmetric Key via PKE (5)

  • Solution 3:
    • S determines secret key K
    • S encrypts K with both kPRIV-S & kPUB-R :

C = E(kPUB-R , E(kPRIV-S, K))

    • S sends C to R
    • R decrypts C to get K:

D( kPUB-S , D(kPRIV-R, C) )

-- order important ! make sure you see this

(see Fig. 2-11 p.78)

  • Solution 3 is good!
    • Only R can decode K (only R knows kPRIV-R)
    • Authentication: R is assured that S sent C
      • Only S could have encoded K with kPRIV-S
slide22

2H.3. Digital Signatures (1)

  • Outline:
    • a. Problem Definition
    • b. Properties of Electronic Signatures
    • c. Using PKE for Digital Signatures
    • d. Using Hash Fcns for Digital Signatures
slide23

Digital Signatures (2)

  • Problem Definition (1)
  • Motivation:
    • Need to sign and transmit electronic doc’s or msgs, incl. checks
      • Analogous to signing & transmitting „paper” letters, doc’s, etc., incl. checks
  • Roles of signatures (for both paper a& electronic)
    • Proves unforgeability of doc/letter/check
    • Authenticates person S who signed doc/letter/check
    • Provides non-repudiation: S cannot say sb else signed it
    • Facilitates proving integrity (e.g., 2 signed legal copies for 2 parties)
    • Note: signature might not identify the signing person
      • if not legible
slide24

Digital Signatures (3)

Problem Definition (2)

  • Security requirements for digital signatures:
    • Signature will not reveal signer’s private key
    • Only owner of private key can produce a valid signature
    • Verification of a correct signature succeeds
    • Modification of a signed message can be detected

[cf. J. Leiwo]

slide25

Digital Signatures (4)

b. Properties of Electronic Signatures (1)

  • M – msg / Sg(S, M) – signature of S on M

Note: M = C or M = P

M = P – if authentication but no secrecy needed

  • Required properties for electronic signatures:
    • Unforgeable:

Only S can produce the pair [M, Sg(S, M)]

    • Authenticable(can verify authenticity)/ non-repudiable:

R can verify that Sg(S,M) in [M, Sg(S, M)] comes from S

          • Only S could have produced M”+”Sg(S,M)
          • Sg(S, M) is firmly attached to M

M

Sg(S, M)

slide26
Digital Signatures (5)

Properties of Electronic Signatures (2)

M

Sg(S, M)

  • Desirable properties for electr. signatures:
    • Not alterable (assures „integrity”):

Once sent, M”+”Sg(S,M) cannot be

undetectably altered by S, R, or interceptor

[I’d rather consider this a part of „unforgeability” above]

    • Not reusable:

If M is received again, S detects that M is „old”

        • E.g., can’t deposit a copy of a check to „double-deposit”
  • Digital signature is a protocol

that mimics effect of signature on paper

slide27

Digital Signatures (6)

c. Using PKE for Digital Signatures (1)

  • Transmitting signed msgs with PKE
    • Original message:
    • Privacy transformation: C = E(P, KPUB-R)
      • Only R can decrypt it (with KPRIV-R)
    • Authenticity transformation = signing:

Sg = Sg(S, C) = D(C, KPRIV-S)

      • Only S can produce Sg(S, C) (with KPRIV-S)
    • Sent message:
  • Note: Remember that for some PKE algorithms (incl RSA):

D( E(M, _), _ ) = E( D(M, _), _ ) = M (commutativity of E-D)

P

C

Sg

slide28

Digital Signatures (7)

Using PKE for Digital Signatures (2)

  • Transmitting signed msgs with PKE - cont.
    • Received msg:

[ C = E(P, KPUB-R) ]

[Sg = Sg(S, C) = D(C, KPRIV-S)]

    • R verifies Sg with S’s public key KPUB-S:

If E( Sg, KPUB-S) = C, then signature is valid

        • bec. E( Sg, KPUB-S) = E( D(C, KPRIV-S), KPUB-S) = C
    • R decodes C with R’s private key KPRIV-R:

P = D(C, KPRIV-R)

C

Sg

slide29

Digital Signatures (8)

Using PKE for Digital Signatures (3)

  • Properties:

[ C = E(P, KPUB-R) ]

[Sg = Sg(S, C) = D(C, KPRIV-S)]

      • Unforgeability:

If C is forged,

it will not „correspond” to Sg ( i.e., E( Sg, KPUB-S) ≠C )

      • Authenticity:

If Sg is valid, S is authenticated (only S can produce valid S’s signature)

      • Non-repudiation (undeniability):

If Sg is valid, only S could have produced it, and have sent C”+”Sg

C

Sg

slide30

Digital Signatures (9)

d. Using Hash Fcns for Digital Signatures

  • Using hash fcn H in digital signatures

— signature over H(m), not over m length H(m) << length (m)

Before:Now:

m

m

Sg(S, H(m))

Sg(S, m)

m = P or m = C

s = Sg

DA(x) = D(x, KPRIV-A)

EA(x) = E(x, KPUB-A)

Note:

Any alteration of m is detected by B’s „Verify” step even if m is not encoded with KPUB-B —due to use of H(m)

[Fig — cf. J. Leiwo]

slide31

2H.4. Certificates (1)

  • Outline
    • a. Introduction
    • b. Trust Through a Common Respected Individual
    • c. Certificates for Identity Authentication
    • d. Trust Without a Single Hierarchy
slide32

Certificates (2)

a. Introduction (1)

  • Need for trust in human interactions
    • Trust w.r.t.:
      • Individuals
      • Institutions (e.g., bank, hospital, car dealer)
      • Artifacts (e.g., car, Internet browser, software house)
  • Trust in small village vs. big city
    • Small village: implicit trust
      • Everybody knows everybody
      • Mr. X „feels” how much to trust Ms. Y
    • Big city: need to consider trust explicitly
      • Ask around to find trusted entities
        • Inquire friends, office mates, etc. about good car dealer, dentist, etc.
      • Check „reputation databases”

E.g., BBB=Better Business Bureau

slide33

Certificates (3)

Introduction (2)

  • Selected trust characteristics
    • Trust comes in degrees of trust
      • Vs. binary trust (with a single trust threshold)
    • Ubiquity of trust in social and artificial systems
      • Many users/computer systems err by trustingblindly (trust without evidence or verification!)
        • E.g., OS trusts all application pgms – any allowed to run
        • E.g., sers trust unknown web sites with personal data
ad