Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D La Corte in Rete
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Valentina Casola » 5.Public Key Infrastructures


Are public keys “secure”?

Public key algorithms support several security attributes:

  • authentication;
  • integrity;
  • non-repudiation;
  • confidentiality (if used with secret key algorithms).

…but application security depends on how you use them!!

Authenticity of Public Key


Authenticity of Public Key (cont’d)

Problem: How does Alice know that the public key she received is really Bob’s public key?

Problem: How does Alice know that the public key she received is really Bob's public key?


The solution

Rely on some trusted third-party attesting user’s identity.

Rely on some trusted third-party attesting user's identity.


Requirements of Public-Key systems

  • SECRECY of the private key
    • Must be known only to owner.
    • Key ownership = Identity.
  • AVAILABILITY of the public key
    • Must be available to anyone.
    • Requires a public directory.

Public Key Infrastructures

Public Key Infrastructure (PKI) provides the means to bind public keys to their owners and helps in the distribution of reliable public keys in large heterogeneous networks.
NIST

The set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke Public Key Certificates based on public-key cryptography.
IETF PKIX working group

The Key distribution problem

  • Public-key certificate
    • Signed statement specifying the key and identity.
  • Common approach: certificate authority (CA)
    • Single agency responsible for certifying public keys;
    • After generating a private/public key pair, user proves his identity and knowledge of the private key to obtain CA’s certificate for the public key (offline);
    • Every computer is pre-configured with CA’s public key.

Digital Certificates x.509 v3


x.509 fields

  • Version: v1, v2, or v3.
  • Serial #: a unique number.
  • Signature method: The method used to sign the digital certificate (e.g., RSA).
  • Issuer name: The entity whose private key signed the certificate.
  • Valid time period: begin time and end time.
  • Subject name: The entity whose public key is included in the certificate.
  • Subject’s public key: public key and public key method.

Components of the PKI

  • Certification Authorities.
  • Registration Authorities.
  • End Users.
  • Certificate Directories.
  • Root CA(s).
  • Certification Practice Statements (CPS).
  • Certificate Management Protocols & APIs.

Major Issues with CAs and RAs

  • End Entity Registration.
  • Trust models.
  • Certification Practice Statement (CPS).
  • Key management.
  • Certificate Revocation.
  • Publishing Issues.
  • Ownership and Maintenance.
  • Liability.

Public-Key Cryptography Standards

  • PKCS #1: RSA Cryptography Standard.
  • PKCS #3: Diffie-Hellman Key Agreement Standard.
  • PKCS #5: Password-Based Cryptography Standard.
  • PKCS #6: Extended-Certificate Syntax Standard.
  • PKCS #7: Cryptographic Message Syntax Standard.
  • PKCS #8: Private-Key Information Syntax Standard.
  • PKCS #9: Selected Attribute Types.
  • PKCS #10: Certification Request Syntax Standard.
  • PKCS #11: Cryptographic Token Interface Standard.
  • PKCS #12: Personal Information Exchange Syntax Standard.
  • PKCS #13: Elliptic Curve Cryptography Standard.
  • PKCS #15: Cryptographic Token Information Format Standard.

Major Questions about PKI Deployment

  • What mechanisms do users have to trust each other?
  • How can users protect the uniqueness of their private key?
  • How can the privacy needs of individuals be balanced with the corporate need for information?
  • What components of the PKI can be outsourced?
  • Who is liable when problems occur?
  • How can multiple applications work with each other?

Registration

  • Registration Authority (RA)
    • verification of user info;
    • policy enforcement;
    • no liability;
    • only handles registration, not re-issuance, revocation, etc.;
    • works with CA.
  • Registration can be local, or outsourced.

Key management

  • Generation of key-pairs
    • CA, RA, end entity?
  • Storage of private keys at CA
    • smartcards, or on disk.
  • Archival of keys.

Trust Models: Hierarchical Trust

Hierarchical model.

Cross-certification.

Hierarchical model. Cross-certification.


Trust Models: Cross-Certification

Allows transference of trust between hierarchies.

Allows transference of trust between hierarchies.


Policy Issues

  • Verification of Identity.
  • What is being certified?
  • Validity Periods of Certificates.
  • CRL issuance / Certificate Revocation.
  • Publishing.
  • Re-issuance.
  • Scope of clients.
  • All are presented in the Certification Practice Statement (CPS).

Certification Practice Statement

  • Outlines the CA’s practices with regard to
    • certificate issuance and user registration;
    • certificate lifetimes and revocation;
    • trust model and vetting process;
    • certificate publishing practices.
  • Designed for other purposes
    • awareness of customers;
    • limiting liability;
    • outlining procedures for personnel.

Certificate Revocation

  • What constitutes revocation?
  • Push/Pull model of CRLs.
  • Publishing Issues.
  • Real-time verification?
  • Are CRLs the right model?

REVOCATION MODELS:

  • Certificate Revocation Lists (CRLs)
    • Traditional model.
    • Supported by Entrust, Verisign, most CAs.
  • On-line Certificate Status Protocol (OCSP).
  • CRL Distribution Points (CDPs).

New Revocation Models

  • On-line Certificate Status Protocol (OCSP)
    • IETF proposed protocol – introduced by VeriSign;
    • real-time verification of certificates;
    • OCSP responders – provide info to clients;
    • acceptance suspended pending response.
  • Certificate Revocation Trees (Valicert)
    • offers service and product for real-time verification;
    • CRL “trees” – contained within product or at server.

Certificate Directories

  • Lightweight Directory Access Protocol (LDAP)
    • runs on TCP/IP, new life into X.500.
  • Gaining heavy industry support
    • Novell NDS;
    • Microsoft AD, Netscape Directory Servers.
  • Also included in client products
    • msIE, Netscape Communicator;
    • etc.

Interoperability Issues

  • Technical Issues
    • Certificate content, extensions, etc.
    • Import/export of data between products.
    • Support for revocation.
    • Use of directories / publishing issues.
    • Frameworks (CDSA, CAPI, etc.).
  • Policy Conflicts
    • Registration process.
    • Identification.
    • Revocation.
  • Liability Issues
    • Due diligence for CAs, RAs.
    • Largely unclear.

The Italian state of the art on PKIs

  • Concepts
    • Electronic Signature.
    • Advanced Electronic Signature.
    • Digital Signature.
    • Qualified Certification Authority.
  • References: CNIPA site.

OpenSSL functions

Implemented functions:

  • Symmetric Cipher: DES, Blowfish, cast, RC2, RC4, RC5,IDEA, AES(to appear).
  • Authentication codes and Hash functions: MD2, MD4, MD5, SHA1, RIPEMD 160, MDC2, HMAC.
  • Public Key Cryptography and Key management: RSA, DSA, D-H,ECC(to appear).
  • Certificates: X509, X509v3.
  • Input/Output, Data Encoding: asn1, bio, evp, pem, pkcs7, pkcs12.
  • Internal Functions: bn, buffer, lhash, object, stack.

OpenSSL Supported Standards

  • PKCS#1(full), PKCS#7 (almost complete for the types actually used: Data, Signed, and Enveloped), PKCS#8(full), PKCS10(full), PKCS#12.
  • X509v3.
  • ASN.1 with DER encoding.
  • SSLv3 and TLSv1.
  • OCSP.
  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion

Fatal error: Call to undefined function federicaDebug() in /usr/local/apache/htdocs/html/footer.php on line 93