X.509 certicate format X.509 certication models X.

509 authentication methods

X.509 Authentication Service

EHN410 e-Business & Network Security

G. Niezen
University of Pretoria Department of Electrical, Electronic & Computer Engineering

February 19, 2009

G. Niezen

Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

Outline

X.509 certicate format

X.509 certication models

X.509 authentication methods

G. Niezen

Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

Introduction
An X.509 certicate is purchased from a Certicate Authority (trusted third party) by a merchant. Allows a merchant:
to give you his public key in a way that your browser can generate a session key for a transaction, and securely send that to the merchant for use during the transaction (padlock icon on screen closes to indicate transmissions are encrypted).

Once a session key is established, no one can hijack the session User only needs a browser that can encrypt/decrypt with the appropriate algorithm, and generate session keys from truly random numbers Merchants Certicate is available to the public Certicates can be cancelled if secret key is compromised
G. Niezen Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

X.509 authentication service

Distributed set of servers that maintains a database about users Each certicate contains the public key of a user and is signed with the private key of a CA. Is used in S/MIME (Chapter 5), IP Security (Chapter 6), SSL/TLS and SET (Chapter 7). RSA is recommended to use. X.509 initially issued in 1988

G. Niezen

Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

Public-key certicate use

G. Niezen

Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

X.509 certicate

user name expiry date (or validity period) serial number public key for user algorithm ID policy information

G. Niezen

Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

Typical digital signature approach

G. Niezen

Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

X.509 certicate
Serial number unique integer value within issuing CA Algorithm used to sign certicate, together with parameters (little, if any, utility) Issuer unique identier - bit string to uniquely identify CA if X.500 name is reused for different entities Signature - contains hash code of all other elds, encrypted with CAs Lecture 11 private key

G. Niezen

X.509 certicate format X.509 certication models X.509 authentication methods

X.509 notation

Certicates signed with private key of Certication Authority (CA) Notation CAA = CA {V, SN, AI, CA, TA, A, Ap} YX = certicate of user X signed by CA authority Y Y{I} = the signing of I by Y. Consists of I with an encrypted hash code appended

G. Niezen

Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

Obtaining a users certicate

CA signs a certicate with its own secret key

G. Niezen

Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

Obtaining a users certicate

CA signs a certicate with its own secret key Anyone can verify a users certicate, using the CAs public key

G. Niezen

Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

Obtaining a users certicate

CA signs a certicate with its own secret key Anyone can verify a users certicate, using the CAs public key Only CA can place (or modify) a certicate in the directory

G. Niezen

Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

Obtaining a users certicate

CA signs a certicate with its own secret key Anyone can verify a users certicate, using the CAs public key Only CA can place (or modify) a certicate in the directory Certicates are unforgeable

G. Niezen

Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

Obtaining a users certicate

CA signs a certicate with its own secret key Anyone can verify a users certicate, using the CAs public key Only CA can place (or modify) a certicate in the directory Certicates are unforgeable No need to protect certicates in the CAs directory NB: The CAs public key integrity and authenticity is very important!

G. Niezen

Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

Characteristics of certicates generated by CA

Any user with access to the public key of the CA can recover the user public key that was certied.

G. Niezen

Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

Characteristics of certicates generated by CA

Any user with access to the public key of the CA can recover the user public key that was certied. No party other than the CA can modify the certicate without this being detected.

G. Niezen

Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

Guarding the CAs private key

Certicate Signing Unit (CSU) : a high-security tamper-proof box that destroys its contents whenever opened. if the CSU is destroyed, security isnt compromised; signed keys can still be veried using the public key.

G. Niezen

Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

Assymetric distribution of public keys

A and B both ask their own authority for a copy of each others public key certicate. If necessary, the authorities exchange As and Bs certicates. The certicates are forwarded to A and B. A and B can now securely communicate directly.

3 4

What if A and B are in different domains and do not trust a common authority?

G. Niezen

Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

Certication models
Different CAs can be chained together: Flat Certicate Model - Only a few (or one) highly trustworthy CAs. May check certicates by checking with top level CA. Hierarchical Certicate Model - CAs at the top may sign for other CAs. To truly check, you must check signatures all the way to the top. Trust ows from the top down. Distributed Certicate Model - Users decide who (other users, CAs) they will trust. Users may sign for one another (delegation of trust) PGP model

G. Niezen

Lecture 11

X.509 hierarchy

X.509 certicate format X.509 certication models X.509 authentication methods

Certicate revocation
Certicates may need to be revoked before expiry, possible because of: the users secret key is assumed to be compromised the user is no longer certied by this CA the CAs certicate is assumed to be compromised Need to inform all users by some means. A Certicate Revocation List (CRL) is intended to do this - a signed and dated list of all the revoked certicates, regularly updated.

G. Niezen

Lecture 11

CRL format

X.509 certicate format X.509 certication models X.509 authentication methods

The certicate authority

The CA is responsible for: identifying entities before certicate generation ensuring the quality of its own key pair, keeping its private key secret. The CA, before generating a certicate, ought to check that a user knows the private key corresponding to its claimed public key.

G. Niezen

Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

X.509 one-way authentication

Establishes: identity of A and that the message was generated by A. message was intended for B integrity and originality (not replayed) of message tA = timestamp, rA = nonce (unique within expiration time), sgnData = information (guaranteed authenticity and integrity), Kab = optional session key
G. Niezen Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

X.509 Two-way authentication

In addition to one-way authentication, establishes: identity of B and that the reply message was generated by B message was intended for A Integrity and originality of the reply

G. Niezen

Lecture 11

X.509 certicate format X.509 certication models X.509 authentication methods

Three-way authentication

Timestamps need not be checked, signed nonces used If synchronized clocks are not available

G. Niezen

Lecture 11