Digital Certificates and Digital Signatures: Difference between revisions

From
Jump to navigation Jump to search
No edit summary
 
(45 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== PKIv3 architectual model and datastructures conforming to ITU-T X.509 ==
= PKIv3 architectual model and datastructures conforming to ITU-T X.509 =







[[Basic certificate fields]]
'''Introduction/motivation'''
== Introduction/motivation ==
Users of a public key shall be confident that the associated private
Users of a public key shall be confident that the associated private
key is owned by the correct remote subject (person or system) with
key is owned by the correct remote subject (person or system) with
Line 12: Line 12:
to subjects.
to subjects.


'''assertion'''
== assertion ==
The binding is asserted by having a trusted CA
The binding is asserted by having a trusted CA
digitally sign each certificate. The CA may base this assertion upon
digitally sign each certificate. The CA may base this assertion upon
Line 32: Line 32:
to support directory access control.
to support directory access control.


'''X.509v3'''
== X.509v3 ==

[[Basic certificate fields]]


The v3 format extends the v2 format by
The v3 format extends the v2 format by
Line 49: Line 51:




'''Certification path processing'''
== Certification path processing ==

[[path processing algorithm]]
verifies the binding between the subject distinguished name and/or
verifies the binding between the subject distinguished name and/or
subject alternative name and subject public key. The binding is
subject alternative name and subject public key. The binding is
Line 63: Line 67:
trusted CA."
trusted CA."


The path processing actions to be performed are:
== Revocation ==


X.509 defines one method of certificate revocation. This method
(a) Verify the basic certificate information, including:
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.


(1) the certificate was signed using the subject public key
from certificate i-1 (in the special case i=1, this step may be
omitted; if not, use the subject public key from the same
certificate),


== source ==
(2) the certificate validity period includes time T,


ITU-T Recommendation X.509
(3) the certificate had not been revoked at time T and is not
currently on hold status that commenced before time T, (this
may be determined by obtaining the appropriate CRL or status
information, or by out-of-band mechanisms), and


= Flexible and Scalable Public Key Security for SSH secure shell) =
(4) the subject and issuer names chain correctly (that is, the
issuer of this certificate was the subject of the previous
certificate.)


== Abstract ==
(b) Verify that the subject name and subjectAltName extension
A standard tool for secure remote access, the SSH protocol uses public key
(critical or noncritical) is consistent with the constrained
cryptography to establish an encrypted and integrity-protected channel with
subtrees state variables.
a remote server. However, widely-deployed implementations of the protocol are
vulnerable to man-in-the-middle attacks, where an adversary substitutes her public
key for the server’s. This danger particularly threatens a traveling user Bob
borrowing a client machine.
Imposing a traditional X.509 PKI on all SSH servers and clients is neither flexible
nor scalable nor (in the foreseeable future) practical. Requiring extensive work or
an SSL server at Bob’s site is also not practical for many users.


== Overview ==
(c) Verify that the subject name and subjectAltName extension
*covers the problem, that open-source SSH programs have no solution to guarantee that the server's public key is correct.
(critical or noncritical) is consistent with the excluded subtrees
*this approach gives a way to build a flat trust-structure with the effect of secure public keys.
state variables.
*this approach published in European Public Key Infrastructure Workshop 2004(EuroPKI 2004: Samos Island, Greece)


== The Situation ==
(d) Verify that policy information is consistent with the initial
SSH uses public-key cryptography to establish authentication and encrypted communications over unsecured channels. The server presents a public key, and the client machine uses standard cryptography to establish a protected channel with the party knowing the private key, hopefully the server. But the binding of the server’s public key to the identity of the server to which the user intended
policy set:
to connect is not guaranteed. This makes the user susceptible to man-in-the-middle attacks.
The attacker substitutes his public key for the server’s and leads the user to his own SSH-Server. If the user then authenticates via passwords, the attacker can gain complete control of the user’s account. If the client machine will be used from different traveling users, every user needs a list of its favorit SSH servers. It costs to much work to maintain all of the public keys on all machines. This isn't a possibility. Another natural approach would be to establish a traditional hierarchical
PKI for SSH servers, including a trust root, which all SSH clients would know. All SSH servers public keys are bound to a node in the trust hierarchy. Every client checks the trust path before it communicates with a server. This approach does not meet the authors real world constraints, because
this universal trust structure needs to be in place before the traveling user can securely
connect from a remote machine and many system environments do not provide
a natural hierarchy of certifiers or machine names. The authors have checked some other possibilities like building a the “universal PKI” or building a many-rooted trust structure. These solutions couldn't hold the real world constraints (see '''Real-World Constraints'''). At the end, we will look on the question: how do we bring public-key security to SSH, in a way that provides the flexibility and scalability that can permit easy adoption in the real world, without requiring an a priori trust structure or an SSL server?


== The Solution ==
(1) if the explicit policy state variable is less than or equal
*Goals and Real World Constraints
to i, a policy identifier in the certificate shall be in the
*Creating a “Poor Man’s” Certificate
initial policy set; and
*Decentralized Approach. (Implemented)
*Semi-centralized Approach.


== Goals and Real-World Constraints ==
(2) if the policy mapping variable is less than or equal to i,
the policy identifier may not be mapped.


'''Real-World Constraints'''
(e) Verify that policy information is consistent with the
{|
acceptable policy set:
|The user trusts the client machine and his intended remote server to work correctly.
|-
|The user does not trust the server machine he actually connects to until he verifies the server’s identity.
|-
|The user also does not trust the client’s network environment, including its DNS.
|-
|"small delta" means, that for the solution no changes in hardware or structure and only small changes in software are allowed. This is forced, because of reducing costs and fast implementation of a solution.
|}


'''Goals''' (more Real-World Constraints)
(1) if the certificate policies extension is marked critical,
{|
the intersection of the policies extension and the acceptable
|The solution should enable users from borrowed (but trusted) clients to establish trusted connections to their home machines.
policy set shall be non-null;
|-
|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 ==
(2) the acceptable policy set is assigned the resulting
{|
intersection as its new value.
|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:'''
(g) Verify that the intersection of the acceptable policy set and
{|
the initial policy set is non-null.
|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
|}


(h) Recognize and process any other critical extension present in
the certificate.


== Decentralized Approach ==
(i) Verify that the certificate is a CA certificate (as specified
'''Overview'''
in a basicConstraints extension or as verified out-of-band).
{|
|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.
|}


(j) If permittedSubtrees is present in the certificate, set the
constrained subtrees state variable to the intersection of its
previous value and the value indicated in the extension field.


'''Create Hashstore File'''
(k) If excludedSubtrees is present in the certificate, set the
{|
excluded subtrees state variable to the union of its previous
|Configurator program produces pairs of (server name – keyed MAC).
value and the value indicated in the extension field.
|-
|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).
|}


'''Establish SSH connection'''
{|
|The user wants to connect to SSH-server A.
|-
|The modified SSH client requests the hashstore file and requires the input of the passphrase of the user.
|-
|The user authenificates itself with the passphrase. The SSH client generates a symmetric key from the passphrase and decodes the hashstore file (verification of the user like a digital signature).
|-
|Now, the SSH client can extract the associated public key of the SSH server.
|-
|Now the SSH client checks the requested server public key.
|-
|If the keys are matching, the SSH session will be established normally.
|}


== Semi-Centralized Approach ==
(l) If a policy constraints extension is included in the
{|
certificate, modify the explicit policy and policy mapping state
|Proposed and evaluated, not completely implemented.
variables as follows:
|-

|Requires maintenance by Sys-Admins.
(1) If requireExplicitPolicy is present and has value r, the
|-
explicit policy state variable is set to the minimum of its
|Requires LDAP server and a CA.
current value and the sum of r and i (the current certificate
|-
in the sequence).
|Preferably using server certificates instead of server public keys.

|}
(2) If inhibitPolicyMapping is present and has value q, the
policy mapping state variable is set to the minimum of its
current value and the sum of q and i (the current certificate
in the sequence).

(m) If a key usage extension is marked critical, ensure the
keyCertSign bit is set.

If any one of the above checks fail, the procedure terminates,
returning a failure indication and an appropriate reason. If none of
the above checks fail on the end-entity certificate, the procedure
terminates, returning a success indication together with the set of
all policy qualifier values encountered in the set of certificates.


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

== Flexible and Scalable Public Key Security for SSH ==

Latest revision as of 21:27, 15 February 2005

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)

Abstract

A standard tool for secure remote access, the SSH protocol uses public key cryptography to establish an encrypted and integrity-protected channel with a remote server. However, widely-deployed implementations of the protocol are vulnerable to man-in-the-middle attacks, where an adversary substitutes her public key for the server’s. This danger particularly threatens a traveling user Bob borrowing a client machine. Imposing a traditional X.509 PKI on all SSH servers and clients is neither flexible nor scalable nor (in the foreseeable future) practical. Requiring extensive work or an SSL server at Bob’s site is also not practical for many users.

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 Situation

SSH uses public-key cryptography to establish authentication and encrypted communications over unsecured channels. The server presents a public key, and the client machine uses standard cryptography to establish a protected channel with the party knowing the private key, hopefully the server. But the binding of the server’s public key to the identity of the server to which the user intended to connect is not guaranteed. This makes the user susceptible to man-in-the-middle attacks. The attacker substitutes his public key for the server’s and leads the user to his own SSH-Server. If the user then authenticates via passwords, the attacker can gain complete control of the user’s account. If the client machine will be used from different traveling users, every user needs a list of its favorit SSH servers. It costs to much work to maintain all of the public keys on all machines. This isn't a possibility. Another natural approach would be to establish a traditional hierarchical PKI for SSH servers, including a trust root, which all SSH clients would know. All SSH servers public keys are bound to a node in the trust hierarchy. Every client checks the trust path before it communicates with a server. This approach does not meet the authors real world constraints, because this universal trust structure needs to be in place before the traveling user can securely connect from a remote machine and many system environments do not provide a natural hierarchy of certifiers or machine names. The authors have checked some other possibilities like building a the “universal PKI” or building a many-rooted trust structure. These solutions couldn't hold the real world constraints (see Real-World Constraints). At the end, we will look on the question: how do we bring public-key security to SSH, in a way that provides the flexibility and scalability that can permit easy adoption in the real world, without requiring an a priori trust structure or an SSL server?

The Solution

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

Goals and Real-World Constraints

Real-World Constraints

The user trusts the client machine and his intended remote server to work correctly.
The user does not trust the server machine he actually connects to until he verifies the server’s identity.
The user also does not trust the client’s network environment, including its DNS.
"small delta" means, that for the solution no changes in hardware or structure and only small changes in software are allowed. This is forced, because of reducing costs and fast implementation of a solution.

Goals (more Real-World Constraints)

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

Establish SSH connection

The user wants to connect to SSH-server A.
The modified SSH client requests the hashstore file and requires the input of the passphrase of the user.
The user authenificates itself with the passphrase. The SSH client generates a symmetric key from the passphrase and decodes the hashstore file (verification of the user like a digital signature).
Now, the SSH client can extract the associated public key of the SSH server.
Now the SSH client checks the requested server public key.
If the keys are matching, the SSH session will be established normally.

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.
Retrieved from "https://sarwiki.informatik.hu-berlin.de/index.php?title=Digital_Certificates_and_Digital_Signatures&oldid=3168"