An Introduction to Security Concepts and Public Key Infrastructure PKI

1
An Introduction toSecurity Concepts andPublic
Key Infrastructure (PKI)
Mary Thompson
2
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
• Authorization
• Identity combined with an access policy grants
  the rights to perform some action

3
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

4
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

5
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

6
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)

7
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
• decrypt the signature with the sender's public
  key
• the result of which should match the hash

8
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

9
X.509 Identity Certificates

• Distinguished Name of user
• CUS, OLawrence Berkely National Laboratory,
  OUDSD, CNMary R. Thompson
• DN of Issuer
• CUS, OLawrence Berkely National Laboratory,
  CNLBNL-CA
• Validity dates
• Not before ltdategt, Not after ltdategt
• User's public key
• V3- extensions
• Signed by CA

10
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

11
LDAP server

• Lightweight Directory Access Protocol
• 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.

12
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 authenticates
  the client to the server
• establish a shared symetric key (the session key)
• uses the session key to encypt all data over the
  secure channel
• Gives you authentication, message integrity and
  confidentiality
• Everything except authorizaton

13
SSL Handshake

• Negotiate the cipher suite
• Establish a shared session key
• Authenticate the server (optional)
• Authenticate the client (optional)
• Authenticate previously exhanged data

14
SSL handshake details

• Client hello
• Client challenge
• Available cipher suites (eg RSA RC4/40 MD5)
• Server hello
• Server certificate
• Connection ID
• Selected cipher suite
• Server adapts to client capabilities
• Optional certificate exchange to authenticate
  server/client
• Commercial sites only use server authentication

15
SSL Handshake - details
Client
Server
Generate Challenge Define Protocols
Challenge
Encryption protocols
Return Server Certificate Generate connection
ID Confirm Protocols
Server Cert
Verify server certificate
Connection Id
Encryption protocols
Decrypt session key Generate server read/write
Key pairs
Generates session key Generate Client read/write
key pairs Encyrpt session key
(Session Key) Server's public key
Encrypt random challenge phrase
Decrypt and verify challenge phrase
(Client's Challenge) Server Write Key
16
SSL Handshake
Client Authentication
Client
Server
Generate new challenge Requests Client certificate
Decrypt challenge
(Challenge phrase) Server write key
Decrypt Message Digest and Client Certificate
Calculate message digest on Challenge and
Server certificate
Message Digest Client Certificate Client
private key
Verify Client certificate and recompute message
digest
Done
(Session Identifier) Server's write key
17
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

18
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

19
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.t
  xt
• openSSL http//www.openssl.org/
• Certificates
• http//futile.lbl.gov/mecury/cappt/index.html

20

Akenti - Certificate-based Access Control for
Widely Distributed Resources
Abdelilah Essiari Gary Hoo Keith Jackson
William Johnston Srilekha Mudumbai Mary Thompson
21
Motivation

• 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 for
  stakeholders to remotely specify access control
  for their resources

22
Goals

• Access based on policy statements made by
  stakeholders
• Handle multiple independent stakeholders for a
  single resource
• Use Public Key Infrastructure standards to
  identify users and create digitally signed
  certificates
• Emphasize usability

23
Approach

• Public Key Infrastructure (PKI)
• Architecture
• Usability features

24
Public Key Infrastructure

• Provides a uniform way for organizations to
  identify people or other entities through X.509
  identity certificates containing public keys.
• These certificates and keys can be used though
  secured connections (SSL) and possession of a
  private key to establish the identity of the
  entities on the connection.
• The keys can be used to provide digital
  signatures on documents. The authors and
  contents of signed documents can be verified at
  the time of use.
• Public Key Infrastructure is beginning to be
  widely deployed in terms of organizations running
  Certificate Authorities.

25
Akenti Access Control

• Minimal local Policy Files (authorization files).
  Who to trust, where to look for certificates.
• Based on the following digitally signed
  certificates
• X.509 certificates for user authentication
• UseCondition certificates containing stakeholder
  policy
• Attribute certificates in which a trusted party
  attests that a user possesses some attribute,
  e.g. training, group membership
• Can be called from any application that has an
  authenticated users identity certificate and a
  unique resource name, to return that users
  privileges with respect to the resource.

26
Required Infrastructure

• Certificate Authority to issue identity
  certificates (required)
• SSLeay provides simple CA for testing
• Netscape CA - moderate cost and effort
• Enterprise solutions - Entrust, Verisign,
• Method to check for revocation of identity
  certificates (required)
• LDAP server - free from Univ. of Mich.. Or comes
  with Netscape CA
• Certificate Revocation lists - supported by most
  CAs
• Network accessible ways for stakeholders to store
  their certificates (optional)
• Web servers
• MSQL web accessible data bases

27

AKENTI ARCHITECTURE
Cache Manager
Fetch Certificate
DN
Resource Server
Client
Akenti
DN
DN
Identity (X509) certificate on behalf of the user.
Log Server
Internet

Use condition or attribute certificates
LDAP
File Servers
Database Server
Web Server
DN
Identity certificates
Certificate Servers
28

AKENTI CERTIFICATE MANAGMENT
Stakeholders
S3
S4
S1
S2
Certificate Generator
C4(S4)
C1(S1)
C2(S2)
C3(S3)
Certificate Servers
Akenti
Hash Generator
Search based on resource name, user DN, and
attribute
29
Emphasis on usability

• Akenti certificate generators provide a user
  friendly interface for stakeholders to specify
  the use constraints for their resources.
• User or stakeholder can see a static view of the
  policy that controls the use of a resource.
• Akenti Monitor applet provides a Web interface
  for a user to check his access to a resource to
  see why it succeeded or failed.

30
Vulnerabilities

• Distributed certificates might not be available
  when needed.
• Independent stakeholders may create a policy that
  is inconsistent with what they intend. Easy to
  deny all access.

31
Related Work

• Ellison, et.al. SPKI - authorization certificates
• Nekander Partanen (HUT) SPKI style certificates
  for access permissions on Java code. To replace
  per/machine Java policy files.
• Blaze,Feigenbaum Policy Maker and KeyNote based
  on authorization certificates written in a
  specified executable language.
• Foster, Kesselman Globus Use of X.509 identity
  certificates to authenticate users.

32
Status

• Akenti enabled Apache Web servers deployed at
  LBNL and Sandia.
• Controlling Akenti code distribution, secure
  data/image repository, ORNL electronic notebooks
• We have given code to CONDOR, Univ. of Wisc.,
  WebFlow at Syracuse Univ., NIST, and ISI/USC
• Servers run on Solaris, but client code runs on
  Linux as well
• Java interface to Akenti policy engine exists and
  is used by the Anchor agent code.

33
Future Directions

• Implement Akenti as a standalone server
• Expand Use Conditions to include dynamic
  variables such as time-of-day, originating IP
  address, state variables.
• Change syntax of certificates, probably to XML.
  We already have a Matchmaker want-ad style in
  addition to our original key-word/value syntax.
• Add delegation - probably in the form of
  authorization certificates
• Integrate with additional applications
• Network bandwidth Quality of service,
• Secure Mobile agents,
• Group key agreement protocol.

34
Conclusions

• As enterprises deploy PKI, identifying users by
  their identity certificates will become natural
  and transparent.
• Currently there are several competing standards
• browsers, Netscape and Explorer
• Entrust - own client interface
• Akenti/SSL overhead acceptable for medium grained
  access checking. E.g , starting an operation,
  making a authenticated connection.
• Ease of use for stakeholders must be emphasized.