Digital Certificates and Digital Signatures

PKIv3 architectual model and datastructures conforming to ITU-T X.509

Introduction/motivation

  Users of a public key shall be confident that the associated private
  key is owned by the correct remote subject (person or system) with
  which an encryption or digital signature mechanism will be used.
  This confidence is obtained through the use of public key
  certificates, which are data structures that bind public key values
  to subjects.  

assertion

  The binding is asserted by having a trusted CA
  digitally sign each certificate. The CA may base this assertion upon
  technical means (a.k.a., proof of posession through a challenge-
  response protocol), presentation of the private key, or on an
  assertion by the subject.  A certificate has a limited valid lifetime
  which is indicated in its signed contents.  Because a certificate's
  signature and timeliness can be independently checked by a
  certificate-using client, certificates can be distributed via
  untrusted communications and server systems, and can be cached in
  unsecured storage in certificate-using systems.

  ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was
  first published in 1988 as part of the X.500 Directory
  recommendations, defines a standard certificate format [X.509]. The
  certificate format in the 1988 standard is called the version 1 (v1)
  format.  When X.500 was revised in 1993, two more fields were added,
  resulting in the version 2 (v2) format. These two fields may be used
  to support directory access control.

X.509v3

Basic certificate fields

  The v3 format extends the v2 format by
  adding provision for additional extension fields.  Particular
  extension field types may be specified in standards or may be defined
  and registered by any organization or community. In June 1996,
  standardization of the basic v3 format was completed [X.509].

  ISO/IEC/ITU and ANSI X9 have also developed standard extensions for
  use in the v3 extensions field [X.509][X9.55].  These extensions can
  convey such data as additional subject identification information,
  key attribute information, policy information, and certification path
  constraints.

Certification path processing

path processing algorithm

  verifies the binding between the subject distinguished name and/or
  subject alternative name and subject public key.  The binding is
  limited by constraints which are specified in the certificates which
  comprise the path. The basic constraints and policy constraints
  extensions allow the certification path processing logic to automate
  the decision making process.

  The "most-trusted CA" is a matter of policy: it could be a root CA in
  a hierarchical PKI; the CA that issued the verifier's own
  certificate(s); or any other CA in a network PKI.  The path
  validation procedure is the same regardless of the choice of "most-
  trusted CA."

Revocation

  X.509 defines one method of certificate revocation.  This method
  involves each CA periodically issuing a signed data structure called
  a certificate revocation list (CRL).  A CRL is a time stamped list
  identifying revoked certificates which is signed by a CA and made
  freely available in a public repository.  Each revoked certificate is
  identified in a CRL by its certificate serial number.

source

 ITU-T Recommendation X.509

Flexible and Scalable Public Key Security for SSH secure shell)

Overview

• covers the problem, that open-source SSH programs have no solution to guarantee that the server's public key is correct.
• this approach gives a way to build a flat trust-structure with the effect of secure public keys.
• this approach published in European Public Key Infrastructure Workshop 2004(EuroPKI 2004: Samos Island, Greece)

The Solution

• Goals
• Creating a “Poor Man’s” Certificate
• Decentralized Approach. (Implemented)
• Semi-centralized Approach.

Goals

The solution should enable users from borrowed (but trusted) clients to establish trusted connections to their home machines.

The solution should be adoptable in the near-term in similar infrastructure (“small delta”).

The solution should accommodate users in domains where sys-admins can set up trustable and usable CA services.

The solution should accommodate users in domains where no such services exist.

The solution should not require that a new universal PKI hierarchy be established before any of this works.

The solution should not require that a user memorize the fingerprints of all servers he wishes to interact with.

Creating a "Poor Man's" Certificate

Modifying SSH protocol violates “small delta” change restriction

Therefore, non SSH mechanism to be used to retrieve server public key

Poor Man’s Certificate: Use HMAC to retrieve server public key securely

HMAC (Hashed Message Authentication Code) is a Keyed MAC Algorithm:

take message M and a secret key k and produces a MAC value Mac(M,k)

infeasible to find another M’, k’ pair that generate the same keyed MAC (collision resistant)

It’s like digital signature, but with symmetric key instead of a key pair

Decentralized Approach

Overview

No Third Party involved.

Individually maintained by user.

User must have access to a web server to retrieve files.

Hashstore-file containing a list of server names, and (for each server) the keyed MAC.

Create Hashstore File

Configurator program produces pairs of (server name – keyed MAC).

Program input = passphrase, target server name(s), path to public keys of this server.

A symmetric (secret) key is generated from passphrase.

Symmetric key is used to calculate keyed MAC.

Keyed MAC = hashed public key of server.

Hashstore-file is stored under public access (Web-Server).

Semi-Centralized Approach

Proposed and evaluated, not completely implemented.

Requires maintenance by Sys-Admins.

Requires LDAP server and a CA.

Preferably using server certificates instead of server public keys.