An Introduction to

Distributed Security Concepts and

Public Key Infrastructure (PKI)

Mary Thompson, Oleg Kolesnikov

Berkeley National Laboratory,
1 Cyclotron Rd,
Berkeley, CA 94720
 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.

M.Thompson, O.Kolesnikov, Berkeley National Laboratory

 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

M.Thompson, O.Kolesnikov, Berkeley National Laboratory

 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

M.Thompson, O.Kolesnikov, Berkeley National Laboratory

 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.
M.Thompson, O.Kolesnikov, Berkeley National Laboratory
 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.

M.Thompson, O.Kolesnikov, Berkeley National Laboratory

 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.

M.Thompson, O.Kolesnikov, Berkeley National Laboratory

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

M.Thompson, O.Kolesnikov, Berkeley National Laboratory

 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
M.Thompson, O.Kolesnikov, Berkeley National Laboratory
 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

M.Thompson, O.Kolesnikov, Berkeley National Laboratory

 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

M.Thompson, O.Kolesnikov, Berkeley National Laboratory

 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
M.Thompson, O.Kolesnikov, Berkeley National Laboratory
 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)

M.Thompson, O.Kolesnikov, Berkeley National Laboratory

 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

M.Thompson, O.Kolesnikov, Berkeley National Laboratory

 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

M.Thompson, O.Kolesnikov, Berkeley National Laboratory

 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
M.Thompson, O.Kolesnikov, Berkeley National Laboratory
 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

M.Thompson, O.Kolesnikov, Berkeley National Laboratory

 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.

M.Thompson, O.Kolesnikov, Berkeley National Laboratory

 SSL / TLS

 SSLv3.1 = TLS v1.0; NB: 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

M.Thompson, O.Kolesnikov, Berkeley National Laboratory

 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]

M.Thompson, O.Kolesnikov, Berkeley National Laboratory

 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
M.Thompson, O.Kolesnikov, Berkeley National Laboratory
 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

M.Thompson, O.Kolesnikov, Berkeley National Laboratory

 Status

 Single purpose CA’s e.g. Globus (SSLeay) Collaboratory,

DOE-Grid (Netscape)
 Enterprises slow to run CA’s
 Many different Vendors - Verisign, Entrust, Netscape, RSA
Security Keon
 Incompatible Key and Certificate management between
vendors
 Certificates are not integrated with existing applications that
need authorization
 Large amount of corporate overhead in running a CA
 Uncertain legal implications of issuing certificates
 Lab is currently looking at the RSA Keon server as it has
integration with ssh and NIS authorization

M.Thompson, O.Kolesnikov, Berkeley National Laboratory

Public Key Cryptography Standards - PKCS

 PKCS 7
 Cryptographic Message Syntax Standard
 PKCS 10
 Certification Request Syntax Standard - used by Netscape
browser, IE, and SSL libraries
 PKCS 11
 Cryptographic Token Interface Standard - An API for
signing and verifying data by a device that holds the key
 PKCS 12
 Personal Information Exchange Syntax Standard - file
format for storing certificate and private key - used to move
private information between browsers

M.Thompson, O.Kolesnikov, Berkeley National Laboratory

 References

 Peter Guttman's tutorial

 http://www.cs.auckland.ac.nz/~pgut001/tutorial/
about 500 slides covering cryptography, secure connection
protocols, PKI, politics and more.
 RSA Laboratories PKCS specifications

 http://www.rsasecurity.com/rsalabs/pkcs/
 SSL/TLS
 TLS v 1.0 RFC - http://www.ietf.org/rfc/rfc2246.tx.
 SSL-v3
http://www.netscape.com/eng/ssl3/draft302.txt
 OpenSSL http://www.openssl.org/

M.Thompson, O.Kolesnikov, Berkeley National Laboratory