Introduction Ticket

Document Sample
Introduction Ticket Powered By Docstoc
					Key Management



• Chapter 10 in Computer Security: Art and
• Handbook of Applied Cryptography
  – Section 11.3.2 attack on RSA signature
  – Section 13.8.3 Key Escrow

      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


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

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

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

        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

          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
• 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,
   – 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
                  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

                 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

          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

      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

                 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

  – 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
                    Shared Channel

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

                     Key Exchange
                    Regular data network              KA
          Classical Key Exchange
• “Classical” means “no public key
• Bootstrap problem: how do Alice, Bob
  – 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
                     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
• 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
          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
• Simple protocol
  – ks is desired session key

                        { ks } eB
  Alice                                         Bob

              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


• Can include message enciphered with ks
• Assumes Bob has Alice’s public key, and vice
   – 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)

                   Man-in-the-Middle Attack

Alice     Pls send Bob’s public key       Eve intercepts request
                                         send Bob’s public key
                                   Eve                             Cathy
                                   Eve                             Cathy
        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

• 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?

• Bob gets Alice’s certificate
   – If he knows Cathy’s public key, he can validate the
       • 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
   – That is, secure distribution of public keys
   – Solution: Public Key Infrastructure (PKI) using trust
     anchors called Certificate Authorities (CAs) that issue
                  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
                       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

                        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

               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


                                   – Offloads burden on multiple CAs
                                   – Need to verify a chain of
                                   – 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”
         Validation and Cross-Certifying
• Alice’s CA is Cathy; Bob’s CA is Dan; how can Alice validate Bob’s
    – 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

Cert binds dest ID
to dest PK, signed by src

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

    CA            CA


                            –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
• 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

           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

• 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”

               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
     his signature is at “casual”
     level of trust                    Irene
• Alice gets Ellen’s cert
   – Knows Jack, so uses his cert                     Fred
     to validate Ellen’s, then hers
     to validate Bob’s                   Bob

                   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
   – Revocation information circulates to everyone fast
      • Network delays, infrastructure problems may delay


• Certificate revocation list lists certificates that are
• X.509: only certificate issuer can revoke
   – 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

                   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
      • Legal proofs, etc., probably required; not dealt with here

              Simple Approach

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

       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

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

           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

        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

                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
   Digital Signature Algorithm (DSA)
Is a FIPS standard (186-3) proposed by NIST, 1991
See this link

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 =
• 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
   – Use physical devices like “smart card”
      • Key never enters system
      • Card can be stolen, so have 2 devices combine bits to make
        single key

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

Beth, Knobloch, Otten, Simmons, Wichmann 94

• 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

         Example: ESS, Clipper Chip
• Escrow Encryption Standard
   – FIPS 185 (
   – 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

           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
                    User Security Component

       message                                                Programmed at initialization

                              UID             kunique
              64 bits

                                  80 bit session key
                                     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)
 Initialization of User Security Component

           Seed1, Key1, Fam1      Secure Facility
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
            {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

                    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

• Clipper would not decode messages with an invalid
   – 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
              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
• Keys need infrastructure to identify holders, allow
  revoking and possible escrow


Shared By:
Description: Introduction Ticket