1. An Introduction to Distributed Security Concepts and Public Key Infrastructure (PKI)
Mary Thompson
Oleg Kolesnikov

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 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. 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. 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-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. 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. 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 Integrity Authentication
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. 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 Public/Private 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 1 HMAC-MD5
SHA-1 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 signer’s name and signature
To verify
find the sender’s public key
decrypt the signature with the sender's public key
the result of which should match the hash

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

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 <date>, Not after <date>
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 / 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.

20. SSL Handshake
When you type 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. 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. 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/ OK
Date: Wed, 11 Jul :15:47 GMT
[…]
Content-Type: text/html

23. Man-in-the-Middle ConceptEa Ec
Alice
Charlie
Bob Ec Eb
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.

24. 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.)

25. 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 ?

26. 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 ?

27. 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 :)

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

29. Demonstration

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

31. Recommendations Data Link Layer: Network Layer: Transport 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

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

33. Questions ?

34. Thank you !

35. SSL Handshake - details
Client
Server
Generate Challenge
Define Protocols
Challenge
Encryption
protocols
Return Server Certificate
Generate connectiion ID
Confirm Protocols
Server Cert
Verify server certificate
Connection ID
Encryption
protocols
Generates pre-master session key
Encyrpt session key
master-secret = hash(pre-master secret, previous messages)
Generate Client read/write key pairs
Decrypt pre-master session key
master secret = hash (pre-master secret,
previous messages)
Generate server read/write Key pairs
{pre-master session Key}
Server's public
key
Encrypt random challenge phrase
Decrypt and verify challenge phrase
{Client's Challenge}
Server Write Key