Introduction to distributed security concepts and public key infrastructure mary thompson
Citation preview
1. An Introduction to Distributed Security Concepts and Public
Key Infrastructure (PKI) Mary Thompson
2. 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
70s. 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. 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 users 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 users key pair for
establishing her identity
4. 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. Kerberos User - password based authentication based on
late-70s 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. NIS Central server has all the user ids and passwords, dont
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. 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. 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. 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 longterm of keys Authorization Identity combined
with an access policy grants the rights to perform some action
10. 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. 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. 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. 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 HMAC-MD5
SHA-1 HMAC-SHA (recommended)
14. 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 signers name and signature To verify hash the
data find the senders public key decrypt the signature with the
sender's public key the result of which should match the hash
16. 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 , Not after User's public key
V3- extensions Signed by CA Defined in ANS1 notation - language
independent
17. 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. 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. SSL - OpenSSL Secure message passing protocol Developed by
Netscape, now an IETF RFC (TLS Jan '99) Protocol for using one or
two public/private keys to authenticate a sever to a client and by
requiring a client key to authenticate the client to the server
establish a shared symetric key (the session key) uses the session
key to encypt or MAC all data over the secure channel Gives you
authentication, message integrity and confidentiality Everything
except authorizaton
20. SSL Handshake Negotiate the cipher suite Establish a shared
session key Authenticate the server (optional) Authenticate the
client (optional) Authenticate previously exhanged data
21. SSL handshake details Client hello: Client challenge,
client nonce Available cipher suites (eg RSA + RC4/40 + MD5) Server
hello: Server certificate, server nonce Connection ID Selected
cipher suite Server adapts to client capabilities Optional
certificate exchange to authenticate server/client Commercial sites
only use server authentication
22. SSL Handshake - details Client Generate Challenge Define
Protocols Verify server certificate Generates pre-master session
key Encyrpt session key master-secret = hash(pre-master secret,
previous messages) Generate Client read/write key pairs Decrypt and
verify challenge phrase Server Challenge Encryption protocols
Server Cert Connection ID Encryption protocols Return Server
Certificate Generate connectiion ID Confirm Protocols Decrypt
pre-master session key {pre-master master secret = hash (pre-master
secret, session Key} previous messages) Server's public Generate
server read/write Key pairs key {Client's Challenge} Server Write
Key Encrypt random challenge phrase
23. SSL Handshake Client Authentication Client Decrypt
challenge Calculate message digest on Challenge and Server
certificate Done Server (Challenge phrase) Server write key
[Message Digest & Client Certificate] Client private key
(Session Identifier) Server's write key Generate new challenge
Requests Client certificate Decrypt Message Digest and Client
Certificate Verify Client certificate and recompute message
digest
24. Status Single purpose CAs e.g. Globus (SSLeay)
Collaboratory, DOE-Grid (Netscape) Enterprises slow to run CAs 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
25. 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
26. 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/ Certificates
http://futile.lbl.gov/mecury/cappt/index.html