An Introduction to Public Key Infrastructure (PKI)

							        An Introduction to
Distributed Security Concepts and
  Public Key Infrastructure (PKI)




         Mary Thompson
         Oleg Kolesnikov
                    Local Computing


   User sits down in front of the computer
   Responds to the login prompt with a user id and password.
   Machine has a list of all the users and their encrypted
    passwords
   Password never goes across the network
   Passwords are encrypted with a one-way code
   The crypt alogrithm of Unix has been around since mid 70’s.
    Uses a salt to keep identical passwords from having the
    same encryption. Uses only 8 characters, case sensitive.
    Uses 25 iterations of DES.
   Typically broken by guessing and verifying guess or
    snooping the password.
          Remote Access Computing


   User logs in to one or more remote machine(s)
   Each machine has its own copy of userid and
    password for each user
       Changing a password on one machine does not affect the
        other machines
       Each time a user connects to a different machine, she
        must login again
   In the standard Unix login or rsh commands, the user’s
    password is sent in clear text over the network or else
    hosts trust users on the basis of their IP addresses
   Ssh
       encrypts the password before sending it
       or uses a user’s key pair for establishing her identity
    Single Domain Remote Access Computing


   User gets access to many machines in a single
    administrative domain.
   He has a single userid and password for all the machines
   Can login just once to a central trusted server
   Examples
        Kerberos freeware from MIT Project Athena
        NIS - Sun software with remote access comands
                           Kerberos


   User - password based authentication based on late-70’s
    Needham -Schroeder algorithms.
   Kerberos Authentication Server aka KDC (Key Distribution
    Center) shares long-term secret (password) with each
    authorized user.
   User logs in and established a short term session key with
    the AS which can be used to establish his identity with other
    entities, e.g. file system, other hosts or services each of
    which trusts the authority server.
   The authorization mechanism needs to be integrated with
    the each function, e.g. file access, login, telnet, ftp, ...
   The central server is a single point of vulnerablity to attack
    and failure.
   Been in use for 20 years. We are now at version 5.
                              NIS


   Central server has all the user ids and passwords, don’t
    need to store passwords locally.
   Facilitates the same user id and passwords on all machines
    on a network
   Then rlogin and rsh allow the user to have access to all the
    hosts in the hosts.equiv and .rhost files
   No real security, depends IP addresses
   Integrated with NFS to allow access to NFS files from any
    host to which they are exported.
           Cross Domain Authentication


   Holy Grail is to allow a user to login in once and get access
    to a ticket that will identify him to all machines on which he
    is allowed to run.
   Kerberos supports cross realm authentication, but it is
    politically difficult to achieve. Used for multiple AFS/DFS
    cells within a single institution. CMU, DOE weapons labs
   X.509 Identity certificates. An IETF standard. Contains a
    multi-part unique name and a public key. The legitimate
    owner of the certificate has the matching private key.
Motivation for Universal Identity certificate


    Distributed computing environments, collaborative
     research environments
    Resources, stakeholders and users are all distributed
    Spanning organizational as well as geographical
     boundaries, e.g., DOE Collaboratories
    Requires a flexible but secure way to identify users
    Requires a flexible and secure way to identify
     stakeholders
                         Security Levels


   Confidentiality
        Protection from disclosure to unauthorized persons
   Integrity
        Maintaining data consistency
   Authentication
        Assurance of identity of person or originator of data
   Non-repudiation
        Originator of communications can't deny it later - requires long-
         term of keys
   Authorization
        Identity combined with an access policy grants the rights to
         perform some action
                 Security Building Blocks


   Encryption provides
       confidentiality, can provide authentication and integrity
        protection
   Checksums/hash algorithms provide
       integrity protection, can provide authentication
   Digital signatures provide
       authentication, integrity protection, and non-repudiation
                            Keys


   Symetric Keys
       Both parties share the same secret key
       Problem is securely distributing the key
       DES - 56 bit key considered unsafe for financial purposes
        since 1998
       3 DES uses three DES keys
   Public/Private keys
       One key is the mathematical inverse of the other
       Private keys are known only to the owner
       Public key are stored in public servers, usually in a X.509
        certificate.
       RSA (patent expires Sept 2000), Diffie-Hellman, DSA
                    Hash Algorithms

   Reduce variable-length input to fixed-length (128 or
    160bit) output
   Requirements
       Can't deduce input from output
       Can't generate a given output
       Can't find two inputs which produce the same output
   Used to
       Produce fixed-length fingerprint of arbitrary-length data
       Produce data checksums to enable detection of
        modifications
       Distill passwords down to fixed-length encryption keys
   Also called message digests or fingerprints
        Message Authentication Code MAC


   Hash algorithm + key to make hash value dependant on the
    key
   Most common form is HMAC (hash MAC)
       hash( key, hash( key, data ))
   Key affects both start and end of hashing process
   Naming: hash + key = HMAC-hash
       MD5 1 HMAC-MD5
       SHA-1 1 HMAC-SHA (recommended)
                        Digital Signatures


   Combines a hash with a digital signature algorithm
   To sign
       hash the data
       encrypt the hash with the sender's private key
       send data signer’s name and signature
   To verify
       hash the data
       find the sender’s public key
       decrypt the signature with the sender's public key
       the result of which should match the hash
                      Elements of PKI


   Certificate Authorities (CA)
       OpenSSL, Netscape, Verisign, Entrust, RSA Keon
   Public/Private Key Pairs - Key management
   x.509 Identity Certificates - Certificate management
   LDAP servers
                X.509 Identity Certificates



   Distinguished Name of user
       C=US, O=Lawrence Berkely National Laboratory, OU=DSD,
        CN=Mary R. Thompson
   DN of Issuer
       C=US, O=Lawrence Berkely National Laboratory, CN=LBNL-CA
   Validity dates:
       Not before <date>, Not after <date>
   User's public key
   V3- extensions
   Signed by CA
   Defined in ANS1 notation - language independent
                    Certificate Authority



   A trusted third party - must be a secure server
   Signs and publishes X.509 Identity certificates
   Revokes certificates and publishes a Certification Revocation
    List (CRL)
   Many vendors
       OpenSSL - open source, very simple
       Netscape - free for limited number of certificates
       Entrust - Can be run by enterprise or by Entrust
       Verisign - Run by Verisign under contract to enterprise
       RSA Security - Keon servers
                         LDAP server



   Lightweight Directory Access Protocol (IETF standard)
       Evolved from DAP and X.500 Identities
   Used by CA's to store user's Identity Certificate
   Open source implementations
   Standard protocol for lookup, entry, etc.
   Access control is implemented by user, password.
                     SSL / TLS

   Secure Sockets Layer/Transport Layer Security Protocol
   SSLv3.1 = TLS v1.0; WTLS -- TLS for Wireless Links
   Works over TCP; Application Independent.



     SSL/TLS allows client/server apps to
     communicate via a protected channel.

   Common example -- HTTP over SSL/TLS, e.g.

                  https://www.entrust.com
                       SSL Handshake


   When you type https://www.entrust.com, browser initiates a
    new SSL/TLS connection.


   For the new connection SSL Handshake must be performed
    which will:
       Negotiate the cipher suite
       Authenticate the server to the client [optional]
       Use public-key algorithms to establish a shared session
        key
       Authenticate the client to the server [optional]
                    SSL Handshake details


   Client hello:
        Client’s challenge, client’s nonce
        Available cipher suites (e.g. DSA/RSA; Triple-DES/IDEA;
         SHA-1/MD5 et al.)
   Server hello:
        Server’s certificate, server’s nonce
        Session ID
        Selected cipher suite
   Server adapts to client capabilities
   Optional certificate exchange to authenticate server/client
        Usually only server authentication is used
             SSL Handshake completed


   After the Handshake is completed, SSL session begins


   Application Data can be transmitted using the established
    SSL connection / session


   Example of Application Data:
    HEAD /index.html HTTP/1.1
    HTTP/1.1 200 OK
    Date: Wed, 11 Jul 2001 08:15:47 GMT
    […]
    Content-Type: text/html
            Man-in-the-Middle Concept



                  Ea                          Ec
    Alice         Ec         Charlie         Eb        Bob

E{a,b,c} = Alice’s, Bob’s, and Charlie’s public keys, respectively



      Alice wants to send secure messages to Bob.
      Charlie intercepts Alice‟s messages.
      Charlie talks to Alice and pretends to be Bob.
      Charlie talks to Bob and pretends to be Alice.
                  MITM Concept (II)



   Alice uses the public key she thinks she received from
    Bob (Charlie‟s)


   Bob uses the key he thinks is Alice‟s (also Charlie‟s)


   As a result, Charlie not only gains access to secure
    information but also can modify it (e.g. transfer money
    to a different account etc.)
     Users under Attack: Secure Browsers



   User is typically presented with a menu asking
    whether to accept new [root] certificate


   Usually, users click on “Yes” and accept new
    certificate without even thinking about the
    consequences


   ~ 60 Root Certificates in my Browser. Did I verify each
    one of them thoroughly ?
               MITM and Certificates



   Digital Certificates designed to solve the problem but
    do they always help ?


   Third party CA signs Alice‟s and Bob‟s public keys so
    they exchange signed keys (certificates) instead


   Good so far ?
                Trusting Certificates



   Problem: Alice and Bob must trust CA


   CA‟s information must be delivered to Alice and Bob
    via Secure Channel


   But how CA‟s information usually gets to Alice and
    Bob ? Via Unprotected Public Network :)
                 How Attackers Work

This is where attackers come into play, they:
   Obtain access to traffic by:
        Breaking into a gateway |
        Spoofing routing tables (RIP/IGP) |
        DHCP entries (default gateway) |
        DNS |
        ARP caches
   Intercept traffic at connection establishment phase and
    generate self-signed PKI certificates to replace
    originals
   Start forwarding data and gain full access to sensitive
    information
Demonstration
                     Implications



   Attackers breaking into core routers/servers, adding
    „transparent forwarding‟, and then using dsniff to
    capture and decrypt HTTPS/SSH1 data


   Government installing their machines at large ISPs
    and using MITM to decrypt HTTPS/SSL, Privacy
    Enhanced Mail (PEM) and other data.
                     Recommendations



   Data Link Layer:
       Enable port security on a switch; use static arp entries


   Network Layer:
       DNSSEC and IPSEC to prevent DNS spoofing
         and sniffing


   Transport Layer:
       Verify root CAs and public keys before adding them; expire
        your public keys; pay attention to key/certificate change
        notifications
                 Things to remember



   User almost always is the weakest link, i.e. social
    aspect.


   Be aware of what do those SSHv1 and SSL
    messages about adding certificates / key change
    mean before typing „y‟


   Be careful with your public keys and make sure your
    party has access to *your* public key
Questions ?
Thank you !
                         SSL Handshake - details

                Client                                                   Server
           Generate Challenge                Challenge
           Define Protocols
                                             Encryption
                                             protocols


                                           Server Cert             Return Server Certificate
              Verify server                                        Generate connectiion ID
                                           Connection ID
              certificate                                          Confirm Protocols
                                           Encryption
                                           protocols


Generates pre-master session key                             Decrypt pre-master session key
Encyrpt session key                        {pre-master       master secret = hash (pre-master secret,
master-secret = hash(pre-master secret,    session Key}              previous messages)
previous messages)                         Server's public
                                           key               Generate server read/write Key pairs
Generate Client read/write key pairs




 Decrypt and verify challenge phrase      {Client's Challenge}   Encrypt random challenge phrase
                                          Server Write Key