1. An Introduction to
Distributed Security Concepts and
Public Key Infrastructure (PKI)
Mary Thompson, Oleg Kolesnikov
Berkeley National Laboratory,
1 Cyclotron Rd,
Berkeley, CA 94720
2. M.Thompson, O.Kolesnikov, Berkeley National Laboratory
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.
3. 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
4. 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
5. 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.
6. 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.
7. 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.
8. 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
9. 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
10. 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
11. 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
12. 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
13. 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)
14. 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
16. 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
17. 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
18. 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.
19. 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
20. 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]
21. 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
22. 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
23. 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
24. 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
25. 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/