Introduction Ticket

Document Sample
Introduction Ticket Powered By Docstoc
					Key Management

 CS461/ECE422




                 1
                   Reading

• Chapter 10 in Computer Security: Art and
  Science
• Handbook of Applied Cryptography
  http://www.cacr.math.uwaterloo.ca/hac/
  – Section 11.3.2 attack on RSA signature
  – Section 13.8.3 Key Escrow



                                             2
      Key Management Motivation

• Cryptographic security depends on keys
  – Size
  – Generation
  – Retrieval and Storage
• Example
  – House security system no good if key or code is
    under the mat

                                                  3
                  Overview

• Key Generation
• Key Exchange and management
  – Classical (symmetric)
  – Public/private
• Digital Signatures
• Key Storage


                                4
             Key Management
Processes associated with
  – Distribution of keys
  – Binding identities to keys
  – Generation, maintenance, and revoking keys
                       Notation

• X  Y : { Z || W } kX,Y
   – X sends Y the message produced by concatenating Z
     and W encrypted 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 encrypted using kA, A’s key, and W encrypted using
     kA,T, the key shared by A and T
• r1, r2 nonces (nonrepeating random numbers)

                                                              6
        Session and Interchange Keys

• Long lived Interchange Keys only exist to boot strap
   – Associated with a principal to the communication, e.g.
     public keys Kb,Ka below
• Short lived session keys used for bulk encryption,
  e.g. Ka,b
 Ka,b                                                Ka,b
 Kb,Ka                                               Ka,Kb
                   {Ka,b}Ka {m1}Ka,b




                                                              7
          Session and Interchange Keys
 • Another view---key and message in one shot
 • Alice wants to send a message m to Bob
     – Assume public key encryption
     – Alice generates a random cryptographic key ks and uses
       it to encrypt m
        • To be used for this message only, not used for authentication
        • Called a session key
     – She encrypts ks with key kB
        • kB encrypts all session keys Alice uses to communicate with
          Bob : known by Bob, shared with Alice
        • Called an interchange key. Used for authentication
     – Alice sends { m } ks ||{ ks } kB


Message m coded with ks               Message ks coded with kB
                                                                          8
                        Benefits
• Limits amount of traffic encrypted with single key
   – Standard practice, to decrease the amount of traffic an
     attacker can obtain
• Prevents some attacks. e.g.,
   – Suppose long lived key (public, or broken) kB
   – Suppose set of possible messages is small, e.g. “BUY”
     or “SELL”
   – Attack can pre-compute possible ciphertexts, observe,
     compare
   – Example: Alice will send Bob message that is either
     “BUY” or “SELL”. Eve computes possible ciphertexts
     { “BUY” } kB and { “SELL” } kB. Eve intercepts
     encrypted message, compares, and gets plaintext at
                                                           9
     once
                  Key Generation
• Goal: generate keys that are difficult to guess
• 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




                                                             10
                 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




                                                                      11
          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




                                                                     12
      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 (mixes key and data), MD5,
    SHA-1, (multi-stage functions in hashing)
    avalanche effect
• Inputs need to be unpredictable


                                                13
                 Key Exchange
Principals to communication need to agree on
  key to be used. Criteria

  – Key should not be transmitted in the clear
     • Solutions : encrypt when sent, derive from public
       keys (e.g. Diffie-Hellman)
     • Assume attacker can view EVERYTHING that is
       transmitted

  – Permissible to use a trusted third party

  – All protocols, mechanisms, algorithms should
    be assumed known. The only secrets are the
    keys involved
               Separate Channel

• Ideally you have separate secure channel for
  exchanging keys
  – Direct secret sharing grows at N2

    Telephone, separate data network, ESP, sneaker net




                 Regular data network
                                                         15
                    Shared Channel


• Generally separate channel is not practical
     – No trustworthy separate channel
     – Want to scale linearly with additional users
                                     KA,KB, … KZ



KB
                     Key Exchange
                    Regular data network              KA
                                                      16
          Classical Key Exchange
• “Classical” means “no public key
  infrastructure”
• 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
                                               17
                     Simple Protocol

         { request for session key with Bob } kA
Alice                                                       Cathy
                        { ks } kA || { ks } kB
Alice                                                       Cathy

                             { ks } kB
Alice                                                       Bob
           Notice : Cathy gives Alice the job of sending key to Bob

                             { ks } kB
Eve                                                         Bob
      Notice : Eve might break key, and entice Bob to use it with her or
      might simply replay the communication Alice had with Bob using
      that key                                                          18
                      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
     • e.g. message is “buy 100 shares of GE stock”
  – Session key reuse: Eve replays message from
    Alice to Bob, so Bob re-uses session key
     • If Eve has cracked session key off-line, she can say
       anything she likes in the communication
• Protocols must provide authentication and
  defense against replay
                                                              19
          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
    owners
• Simple protocol
  – ks is desired session key

                        { ks } eB
  Alice                                         Bob

                                                        42
              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

                                                        43
                              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)




                                                                         44
                   Man-in-the-Middle Attack

Alice     Pls send Bob’s public key       Eve intercepts request
                                                                   Cathy
                                         send Bob’s public key
                                   Eve                             Cathy
                                                    eB
                                   Eve                             Cathy
                     eE
        Alice                      Eve
                Alice believes that eE is Bob’s public key. It isn’t….

                   { k s } eE
                                         Eve intercepts message
    Alice                                                          Bob
                                                { ks } eB                45
                                  Eve                              Bob
     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


                                                            46
                           Certificates
• Create token (message) containing
    –   Identity of principal (here, Alice)
    –   Corresponding public key
    –   Timestamp (when issued)
    –   Other information (perhaps identity of signer)
    –   Compute hash (message digest) of token
Hash encrypted by trusted authority (here, Cathy)
 using private key: called a “signature”
    CA = eA || Alice || T || {h(eA || Alice || T )} dC

OBSERVE : public key, Alice and T are in the clear; hash is signed. Why?


                                                                           47
                            Use
• Bob gets Alice’s certificate
   – If he knows Cathy’s public key, he can validate the
     certificate
       • Decrypt encrypted hash using Cathy’s public key
       • Re-compute hash from certificate and compare
       • Check validity
       • Is the principal Alice?
   – Now Bob has Alice’s public key
• Problem: Bob needs Cathy’s public key to validate
  certificate
   – That is, secure distribution of public keys
   – Solution: Public Key Infrastructure (PKI) using trust
     anchors called Certificate Authorities (CAs) that issue
     certificates
                                                               48
                  X.509 Certificates

• 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: encrypted hash
                                                        49
                       Transitive Trust
• If user U1 has a public-key certificate C issued by
  certificate authority CA1, then CA1 trusts that the identity
  on C is user U1’s
   – Some validation used before C is issued
   – U1 also trusts validity of other certs issued by CA1
• If CA1 has a certificate D issued by CA2, then CA2 trusts
  that the identity on D is CA1’s, and that CA1 does due
  diligence in checking identities on certs that CA1 issues…
   – CA1 trusts other certs that CA2 issues to certificate authorities and
     (possibly) users




                                                                             50
                        Transitive Trust Illustrated
cert issued
                                   Trusts CA3’s identity
                                   and trustworthiness
                                   of certs issued
                         CA2                           CA3
                                       Trusts certs
                                     signed by CA2
Trusts CA1’s identity                                        Trusts CA4’s identity
and trustworthiness                                          and trustworthiness
                           Trusts certs      Trusts certs    of certs issued
of certs issued          signed by CA2     signed by CA3


                 CA1                                       CA4
                                                                     Trusts Bob’s
Trusts Alice’s                                                         identity
   identity                                       Trusts certs
                    Trusts certs                signed by CA4
                  signed by CA1

                                                                 Bob
              Alice
               Suppose Alice has every cert implied in this diagram
                  she trusts the key on Bob’s cert---
               Why? She trusts CA2, and CA2 trusts Bob
                  PKI Trust Models
• A Single Global CA            • Hierarchical CAs (Tree)
   – Unmanageable, inflexible
   – There is no universally                    Root CA
     trusted organization
                                      Level I CA    …     Level I CA

                                       Level n CA

                                         User

                                   – Offloads burden on multiple CAs
                                   – Need to verify a chain of
                                     certificates
                                   – Still depends on a single trusted
                                     root CA                        52
                 PKI Trust Models

• Hierarchical CAs with cross-certification
   – Multiple root CAs that are cross-certified
   – Cross-certification at lower levels for efficiency
• Web Model
   – Browsers come pre-configured with multiple trust
     anchor certificates
   – New certificates can be added
• Distributed (e.g., PGP)
   – No CA; instead, users certify each other to build a “web
     of trust”
                                                           53
         Validation and Cross-Certifying
• Alice’s CA is Cathy; Bob’s CA is Dan; how can Alice validate Bob’s
  certificate?
    – Have Cathy and Dan cross-certify
    – Each issues certificate for the other
• Certificates:
    –   Cathy<<Alice>> (Cathy issues cert for Alice)
    –   Dan<<Bob> (Dan issues cert for Bob)
    –   Cathy<<Dan>> (Cathy issues cert for Dan)
    –   Dan<<Cathy>> (Dan issues cert for Cathy)       Cross-certification




                                                                             54
                              Cross-Certification
Cert binds dest ID
to dest PK, signed by src

                   CA
                                             Alice gets cert from Bob :
                                Cathy         is there a common CA ancestor
           CA               CA               in the directed CA graph?

                                     Alice
    CA            CA
            Dan
                       Cross-certification

             Bob

                            –Alice gets Bob’s cert, signed by Dan
                                –Sees Dan’s cert is signed by Cathy
                                –Trusts Cathy as her own CA
                            –Alice uses (known) public key of Cathy to validate Dan’s cert
                            –Alice uses Dan’s public key (from cert) to validate Bob’s cert
                     PGP Chains
• OpenPGP certificates structured into packets
   – One public key packet
   – Zero or more signature packets
   – See http://www.ietf.org/rfc/rfc4880.txt
• 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


                                                           56
           OpenPGP Signature Packet

• Version 3 signature packet
   –   Version (3)
   –   Signature type (level of trust)
   –   Creation time
   –   Signer’s key identifier (identifies key to encrypt hash)
   –   Public key algorithm (used to encrypt hash)
   –   Hash algorithm
   –   Part of signed hash (used for quick check)
   –   Signature (encrypted hash)
• Version 4 packet more complex
                                                                  57
                        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”




                                                             58
               Validating Certificates

• Alice needs to validate              Arrows show signatures
  Bob’s OpenPGP cert                  Self signatures not shown
   – Does not know Fred,
     Giselle, or Ellen                            Jack
• Alice gets Giselle’s cert
   – Knows Henry slightly, but        Henry
                                                     Ellen
     his signature is at “casual”
     level of trust                    Irene
                                                    Giselle
• Alice gets Ellen’s cert
   – Knows Jack, so uses his cert                     Fred
     to validate Ellen’s, then hers
     to validate Bob’s                   Bob

                                                                  59
                   Key Revocation

• Certificates invalidated before expiration
   – Usually due to compromised key
   – May be due to change in circumstance (e.g., someone
     leaving company)
• Problems
   – Verify that entity revoking certificate authorized to do
     so
   – Revocation information circulates to everyone fast
     enough
      • Network delays, infrastructure problems may delay
        information


                                                                60
                         CRLs

• Certificate revocation list lists certificates that are
  revoked
• X.509: only certificate issuer can revoke
  certificate
   – Added to CRL
• PGP: signers can revoke signatures; owners can
  revoke certificates, or allow others to do so
   – Revocation message placed in PGP packet and signed
   – Flag marks it as revocation message

                                                          61
                   Digital Signature

• Construct that authenticated origin, contents of
  message in a manner provable to a disinterested
  third party (“judge”)
• Sender cannot deny having sent message (service
  is “non-repudiation”)
   – Limited to technical proofs
      • Inability to deny one’s cryptographic key was used to sign
   – One could claim the cryptographic key was stolen or
     compromised
      • Legal proofs, etc., probably required; not dealt with here

                                                                     62
              Simple Approach

• Classical: Alice, Bob share key k
  – Alice sends m || { m } k to Bob
  This is a digital signature
                     WRONG
        This is not a digital signature
  – Why? Third party cannot determine whether
    Alice or Bob generated message

                                                63
       Public Key Digital Signatures

• Alice’s keys are (private) dAlice, (public) eAlice
• Alice sends Bob
                        m || { m } dAlice
• In case of dispute, judge computes
                      { { m } dAlice } eAlice
• and if it is m, Alice’s private key signed message
   – She’s the only one who knows dAlice, so we infer Alice
     did the signing action

                                                              64
          RSA Digital Signatures

• Use private key to encrypt message
  – Protocol for use is critical
• Key points:
  – Never sign random documents, and when
    signing, always sign hash and never document
     • Mathematical properties can be turned against signer
  – Sign message first, then encrypt
     • Changing public keys causes forgery
                                                         65
                         Attack #1
Given Bob’s signatures on messages m1 and m2
Alice can compute his signature on message m  m1  m2
 so the attack is to create evil message m, find factors
                                  
 (with appropriate modulus) and get Bob to sign them

 • (m1 x m2 ) mod nb = m 
 • Get Bob to sign m1 and m2
 • m1d mod nb x m2d mod nb =
              (m1d x m2d ) mod nb =
               (m1 x m2 )d mod nb
              = md mod nb                                  66
                        Attack #1 example
• Example: Alice, Bob communicating
   – nA = 95, eA = 59, dA = 11
   – nB = 77, eB = 53, dB = 17
   – note that ops using Alice’s key are mod nA,, using Bob’s are nB
• 26 contracts, numbered 00 to 25
   – Alice has Bob sign 05 and 17:
      • c = mdB mod nB = 0517 mod 77 = 3
      • c = mdB mod nB = 1717 mod 77 = 19
   – Alice computes 0517 mod 77 = 08; corresponding signature is
      (08)17 mod 77 = (0319) mod 77 = 57;
   – claims Bob signed 08
   – Judge computes ceB mod nB = 5753 mod 77 = 08
      • Signature validated; Bob is toast

                                                                 67
           Attack #2: Bob’s Revenge
• Bob, Alice agree to sign contract m but Bob wants
  it to appear that she signed contract M
   – Alice encrypts with Bob’s public key (e.g. for
     confidentiality), then signs with her private key:
       c = (meB mod nB)dA mod nA
• Bob now changes his public key
   – Computes r such that Mr mod nB = m
   – Replace public key with product reB and computes a new matching
     private key d'B
       • What exactly is the math problem to be solved?
• Bob claims contract was M. Judge computes:
   – (ceA mod nA)d'B mod nB = M


                                                                  68
        Attack #2: Bob’s Revenge (cont’d)
• Document is c = (meB mod nB)dA mod nA
• Bob’s new key pair is (r eB, d’B)
    – M and r satisfy Mr mod nB = m
• What happens if M is encoded using new public key?
    – (M r eB mod nB) = (M r )eB mod nB
                   »     = m mod nB
• Bob claims contract was M. Judge computes:
    –   (ceA mod nA)d'B mod nB = M
    –   Verify Alice signed
    –   Decode using new public key
    –   Busted
• Illustrates dangers of encrypt-then-sign
    – Recipient can pull a fast one on you


                                                       69
                Attack #2 Example

• Bob, Alice agree to sign contract 06
• Alice encrypts, then signs:
   (meB mod 77)dA mod nA = (0653 mod 77)11 mod 95 = 63
• Bob now changes his public key
   – Computes r such that 13r mod 77 = 6; say, r = 59
   – Computes r eB mod (nB) = 5953 mod 60 = 7
   – Replace public key eB with 7, private key dB = 43
• Bob claims contract was 13. Judge computes:
   – (6359 mod 95)43 mod 77 = 13
   – Verified; now Alice is toast
                                                         70
   Digital Signature Algorithm (DSA)
Is a FIPS standard (186-3) proposed by NIST, 1991
See this link
http://www.itl.nist.gov/fipspubs/fip186.htm

Is a bit more technical than it is interesting

That has never stopped us before….
Three phases
   – Key generation
   – Signing
   – Verification
                 DSA Key Generation
Algorithmic parameters
   – Hash function h
   – Key lengths (L, N) 186-3 specifies options
       (1024,160), (2048,224), (2048,256), and (3072,256).
   – Choose an N-bit prime q.
   – Choose an L-bit prime modulus p such that p–1 is a
     multiple of q.
   – Choose g, with multiplicative order modulo p equal to q.
   – (p, q, g) may be shared

Key generation---public and private keys
   – Choose random x, with 0 < x < q.
   – Calculate y = (g x ) mod p.
   – Public key is (p, q, g, y). Private key is x.
                    DSA Signature
• Generate a random per-message value k where 0 < k < q
• Calculate r = ((g k) mod p) mod q
• Calculate s = (k’(H(m) + x*r)) mod q
   – where k’ is the multiplicative inverse mod q of k
   – Remember that x is private key
• Recalculate the signature in the unlikely case that r = 0 or s =
  0
• The signature is (r, s)
                   DSA Verification
Given legal signature (r, s)
•   Calculate w = (s’) mod q
       • s’ multiplicative inverse mod q

•    Calculate u1 = (h(m)*w) mod q
    – m is message whose signature we’re checking

•    Calculate u2 = (r*w) mod q

•    Calculate v = ((gu1 * yu2) mod p) mod q

•    The signature is valid if v = r
                      Storing Keys

• Multi-user or networked systems: attackers may
  defeat access control mechanisms
   – Encrypt file containing key
      • Attacker can monitor keystrokes to decrypt 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

                                                                      75
                    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
                                                         76
                   Desirable Properties
    • Escrow system should not depend on encryption
      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

                                                      77
Beth, Knobloch, Otten, Simmons, Wichmann 94
                Components

• User security component
  – Does the encryption, decryption
  – Supports the key escrow component
• Key escrow component
  – Manages storage, use of data recovery keys
• Data recovery component
  – Does key recovery

                                                 78
         Example: ESS, Clipper Chip
• Escrow Encryption Standard
   – FIPS 185 (http://www.itl.nist.gov/fipspubs/fip185.htm)
   – Set of interlocking components
   – Designed to balance need for law enforcement access to
     enciphered traffic with citizens’ right to privacy
• Clipper chip given to user with prepared per-
  message escrow information
   – Each chip numbered uniquely by UID
   – Special facility programs each chip
• Key Escrow Decrypt Processor (KEDP)
   – Available to agencies authorized to read messages

                                                          79
           User Security Component

• Unique device key kunique
• Non-unique family key kfamily
• Cipher is Skipjack
   – Classical cipher: 80 bit key (ksession ), 64 bit input,
     output blocks
• Attaches Law Enforcement Access Field (LEAF)
  of 128 bits:
   – { UID || { ksession } kunique || hash } kfamily
   – hash: 16 bit authenticator from session key and
     initialization vector
                                                               80
                    User Security Component

       message                                                Programmed at initialization


                              UID             kunique
              64 bits

                                  80 bit session key
                  skipjack
                                     ksession                        Based on session key and
                                                                     Initialization vector
              64 bits                       k family
Law Enforcement         {UID|| ksession }kunique || hash}k family
Access Field
                         (32)     (80)                      (16)

                           
                                      Field sizes (in bits)
  ciphertext
         
 Initialization of User Security Component

           Seed1, Key1, Fam1      Secure Facility
Escrow
Agent I       {ku1}kcomp       •Creates ku1,ku2
                           •Combine Fam1, Fam2
                             to obtain kfamily   UID, kunique,
                           •Combine Key1,Key2 kfamily            User
                           to obtain kcomp                   “Clipper”
         Seed2, Key2, Fam2 •Combine Seed1, Seed2                 Chip
Escrow
            {ku2}kcomp     to generate sequence
Agent II                   kunique = ku1  ku2

Essential points
• Key that encrypts session key requires both ku1 and ku2
• k family depends on input from both Escrow agents
• Returned encoding of ku1,ku2 uses key derived from both
  Escrow agents                                                  82
                                           
                   Obtaining Access

• Alice obtains legal authorization to read message
• She runs message LEAF through KEDP
   – LEAF is
      { UID || { ksession } kunique || hash } kfamily
• KEDP uses (known) kfamily to validate LEAF (think
  hash(UID)), obtain sending device’s UID
• Authorization, LEAF taken to escrow agencies
   – To get session key she needs to get kunique

                                                        83
                    Agencies’ Role

• Each validates authorization offered by Alice
• Each supplies { kui } kcomp and key number Keyi
• KEDP takes these and LEAF:
   { UID || { ksession } kunique || hash } kfamily
   –   Key numbers produce kcomp
   –   kcomp produces ku1 and ku2
   –   ku1 and ku2 produce kunique
   –   kunique and LEAF produce ksession


                                                     84
                          Problems
• Clipper would not decode messages with an invalid
  hash
   – So naturally the attack is to replace the real LEAF with
     one that has a valid hash!
• hash too short
   – LEAF 128 bits, 16-bit “checksum” (hash)
   – 2112 LEAFs have a valid hash, e.g., would validate
      • 1 has actual session key, UID
      • Takes about 42 minutes to find a randomly generated LEAF with
        a valid hash but meaningless session key and UID
          – Turns out deployed devices would prevent this attack
   – Scheme does not meet temporal requirement
      • As kunique fixed for each unit, once message is read, any future
        messages can be read
                                                                           85
              Yaksha Key Escrow
Main ideas:
  – Session keys obtained from a Yaksha server
     • Server escrows generated keys
  – Only messages encoded with the session key
    are recoverable
                          Key Points

• Key management critical to effective use of cryptosystems
   – Different levels of keys (session vs. interchange)
• Exchange algorithms can be vulnerable to attacks
   – Replay
   – Identity integrity
• Digital signatures provide integrity of origin and content
   Much easier with public key cryptosystems than with classical
    cryptosystems
• Keys need infrastructure to identify holders, allow
  revoking and possible escrow


                                                                   88

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:10
posted:12/19/2010
language:English
pages:65
Description: Introduction Ticket