AcademiaTehnicaMilitaraBucuresti

20102011

Curs:

SECURITATEINFORMATICA

Prof.Dr.VictorValeriuPATRICIU

B.ElectronicSignaturesandPKI

AUTENTIFICAREA PRIN SEMNATURI ELECTRONICE

Semnaturi, Certificate digitale,
Liste de revocare, Cai de certificare
Componente PKI : CA, RA, Repository, Useri
Arhitectur PKI
Certificate X.509
CRL-uri
Construirea si validarea cailor de certificare
Time-Stamping

Digital (Electronic) Signature

-creating & verifying-

Digital Signatures

It signs a message digest

Two digital algorithm types:
- digital signature with message recovery (ex.RSA)
- digital signature without message recover (ex.DSA)

Digital Signatures
with Message Recovery

without Message Recovery

Recommended Signature Key Length and Algorithms

-for e-commerce use-

Signature

Algorithms

-1024 bits key RSA;

-1024 bits key DSA;
-160 bits key DSA with elliptic curves
Hash Functions:
-RIPEMD 160
-SHA-1

Public-Key Distribution

Public-Key Distribution

Digital Certificate
Is a person really who claim?
How do you know that the public key
you got from a person really bellongs to
this person?

Solution: CERTIFICATE- like an

Information Highway Driver Licence

Digital Certificate X 509 V3

Certificate contents:

Version number is 3
Serial number is a monotonically
increasing integer value (guaranties
the unicity of serial number for
issuing CA)
Issuer name is populated with X.500
di ti
distinguished
i h d name
Subject public key corresponds to a
standard algorithm
Signature field identifies a standard
signature algorithm.

Digital Certificate X 509 V3

-extensionsX.509 v3 standard extensions -separated into groups:
1. key information (authority key identifier, subject key identifier, key
usage private key usage period)
usage,
2. policy information (certificate policies and policy mappings)
3. user and CA attributes (subject alternative name, issuer alternative
name, subject directory attributes)
4. certification path constraints (basic constraints, name constraints,
policy constraints)
Coments:

Authority key identifier extension contains a key identifier, if not necessary

the issuer name and the serial number

CRL distribution points extension contains the location where CRL may be
found

Authority information access extension contains the repository in which the

own CA certificate may be found

Sample Digital Certificate

End-Entity Certificates

Are issued to subjects that are not CAs

CA s
Contain public keys used for verifying digital
signatures or for performing key management
Subject: human user or system (Web server or
router)
2 types:
- User certificates
- System certificates

End-Entity Certificates
User certificates

System certificates

Subject name

is populated with X.500

X 500
distinguished name or DNS
style

is populated with X.500

X 500
distinguished name or DNS
style

Validity period

No more than 3 years

No more than 3 years

Is critical extension.

Is critical extension

Key usage extension

Non-critical extension.
For Web servers
servers-SL
SL and TLS
For routers- IPsec

Extended key usage

extension
Certificate policies
extension

Non-critical extension. A single

policy

Non-critical extension. A single

policy

Subject alternative name

extension

Non-critical extension. Includes

the user e-mail address.

Non-critical extension. Includes

the computer DNS name. For
routers contains the IP address.

CA Certificates

Are issued to subjects that are CAs

Are part of certificate paths
Contain public keys used for verifying digital signatures on
certificates and CRLs
Must contain sufficient information for certificate users to
construct certification paths and locate CRLs
Subject: other CA in the same enterprise or a CA in other
enterprise or a bridge
3 types:
- CA certificates within an enterprise PKI
- CA certificates between enterprise PKIs
- CA certificates in a Bridge CA Environment

Self-Issued Certificates

Issuer and Subject are the same

Used to establish trust points, distribute a new signing
public key or modify the certificate policies supported
in a PKI
3 types:
- Trust point establishment
- Rollover certificates (Introduce a new certificate or CRL
signing key. A CA issues a pair of key rollover certificates
simultaneously First-contain
simultaneously.
First contain the old public key
key, signed with
the new private key. Second - contain the new public key,
signed with the old private key. In this way subscribers with
certificates signed with the old private key and subscribers
with certificates signed with the new private key can validate
each others certificates.
- Policy rollover certificates

Public Key Infrastructure

PKI- Set of components (hard & soft), that work

together
g
for using
g in a secure manner p
public-key
y
technology
CA- a trusted authority -which provides a
statement (the Digital Certificate) that the enclosed
public key belongs to the person whose name is
attached
CA a central administration - issues certificates:
CA-organization to its employees
-company to its employees
-university to its students
-public CA (like VeriSign) to their clients

Certificate Authority
CA

ccertificate

Nam
me, public-key

Certificate Directory
(X.500, DNS, etc.)

Encrypted & Signed Message

User

User

CA Hierarchy
Root CA

CA

CA
CA

CA

10

Certificate Revocation

A certificate must be revoked when:

private key
yp
pair is compromised;
p
-the p
-the private key pair is lost;
-the person leaves the company.
All users know to no longer trust in certificates;
Relaying parties check CRL before using a certificate;
Caching a CRL in a local cache
Rather than one long CRL, keep multiple shorter CRLs .
Distribute the CRL to multiple
p p
places and spread
p
the load
using the certificate extension field cRLDistributionPoints.
Use a sufficiently scalable and powerful CR server.
OCSP-On-line Certificate Status Protocol: inquires of
issuing CA wheter a certificate is still valid. (resp. YES/NO)

X.509 CRL format

11

Certificate Verification
with Directory

Certificate Paths

A Certification path is an ordered sequence of

certificates between the end entity and the trusted
point in the hierarchy (i.e.,
(i e root).
root) The result forms a
certificate chain that begins at the end entity and
ends at the root CA
Certificates may be chained to form a certification
path. This is illustrated in figure; User B has been
issued a certificate by CA 3, which has been issued
a certificate by CA 2, which in turn has been issued a
certificate by CA 1.
1 If Uer A trusts CA 1,
1 knows its
public key, he can verify each certificate in the
certification path until he reaches User B certificate
and verifies it. At that point, A now knows Bs public
key and can verify his signatures.

12

Certificate Paths

Two alternative
PKI topologies

13

Cross-Certification

Allows transference of trust between hierarchies

ABC Co.

XYZ Co.

MIT
Sales
Sloan

LCS

Research

London

Corporate
NYC

H.R.

Marketing

PKI Components

The core components of a PKI include:

The End-Entities (EE)

The Certificate Authority (CA)

The Certificate Repository (CR)

The Registration Authority (RA)

Digital Certificates (X.509 V3)

14

PKI Components

End-Entity (EE)
An End-Entity is defined as a user of PKI
certificate and/or end-user system that is the
subject of a certificate
In a PKI system, End-Entity is a generic term
for a subject that uses some services or
functions of the PKI system, which may be a
certificate owner (human being or organization
or some other entities), or a requestor (it might
be application program) for certificate or CRL.

15

Certificate Authority (CA)

The Certificate Authority (CA) is the signer of the
certificates.
tifi t
Th CA,
The
CA often
ft
t
together
th with
ith the
th RA,
RA The
Th
Registration Authority (RA), has the responsibility of
the certificate subject entity's identification.
The logical domain in which a CA issues and manages
certificates is called security domain, which might be
implemented to cover an organization, company, a
large department, a test cell, or another logical
community in real cases.
A CAs primary operations include certificate issuance,
certificate renewal, and certificate revocation.

Registration Authority (RA)

Registration Authority (RA) is an optional
component in a PKI.
In some cases, the CA incorporates the role of an
RA. Where a separate RA is used, the RA is a trusted
End-Entity certified by the CA, acting as a subordinate
server of the CA.
The CA can delegate some of its management
functions to the RA
RA. For example,
example the RA may perform
personal authentication tasks, report revoked
certificates, generate keys, or archive key pairs.
The RA, however, does not issue certificates or
CRLs.

16

Certificate Repository (CR)

CR store, issues & revokes certificates.
X.509 certificate format fit to an X.500 directory,
y a CR is
best implemented as a directory, accessed by Lightweight
Directory Access Protocol (LDAP v3).
RFC 2587, Internet X.509 PKI Operational Protocols LDAPv2, defines the access method to a repository with
which an End-Entity or a CA can retrieve or modify the
certificate and CRL information stored in a CR. CR can be
accessed with LDAP commands or procedures (bind,
(
search,modify, unbind).
RFC 2559, Internet X.509 PKI LDAPv2 Schema, defines the
attributes and object classes to be supported by an
LDAP CR server.

Directories

RFC 2587 specifies 3 object classes

PKI useruser used for certificate holder entries; must contain

a user certificate attribute; all certificates whose subject
name matches the name of entry should be stored in this
attribute
PKI CA- used for CA entries; may contain a CA
certificate, CRL, ARL and cross-certificate pair attributes;
CA certificate attribute contains CA certificates whose
subject name matches the name of entry; these
certificates may be self-issued or issued by other CAs;
CRL distribution point- may include CRL, ARL, and delta
CRL attributes; the name of the entry will match the name
in the CRL distribution point extension;

17

X.500 Directories

Various servers called Directory Server Agents

(
(DSA)
)
Clients called Directory User Agent (DUA)
DSA responds to DUA queries with information
X.500 Directory uses 2 basic protocols:
- Directory Access Protocol (DAP)- supports information
requests from a DUA to a DSA;
- Directory Service Protocol (DSP)- supports information
requests between DSAs; DSAs may augment DSP by
shadowing, with the Directory Information Shadowing
Protocol (DISP), used to replicate the contents of a DSA;

LDAP
Lightweight Directory Access Protocol- v2

Developed by the University of Michigan

Standardised in IETF;;
If a LDAP directory receives a request for an entry that is not
locally held, it checks a table of remote directories; if one directory
is likely to contain the entry, the directory returns a referral to the
other directory;
The referral contains the directory name and the system that
support them;
The architecture does not p
provide transparency;
p
y; a client must
determine the physical location before it obtains any information;
Generally, if certificates or CRLs are not available in the first
LDAP directory checked, they will not be found.
PKI repositories based on LDAP generally use a single repository.
Most CA products include an LDAP client and can perform
authenticated directory updates automatically.

18

Signed Document Format

ETSI Electronic Signature Format- these specifications

define an electronic signature that remains valid over
long periods (see next figure);
to archive this goal, the signature format includes
evidence of its validity, by using a TSA to provide
verifiable time;
the format of signature includes 3 levels of signature:

ES (Electronic Signature) - containes the policy identifier,

signed attributes and digital signature
ES-T- adds the timestamp over digital signature
ES-C- adds references to all the certificates and status
information that apply to this signature(usually CRLs);

ETSI Electronic Signature Format

19

XML Signature
The explosive growth in the use of the Web for business-to-business
(B2B) e-commerce has intensified attention on the eXtensible Markup
L
Language
(XML) a common, open, Internet
I t
t standard
t d d that
th t facilitates
f ilit t
data exchange over the Internet.
Recognizing that existing Web technologies, such as HTML, are
inadequate for implementing the scale and diversity of transaction
protocols envisioned for the Web, the World Wide Web Consortium
(W3C) and the Internet Engineering Task Force (IETF) have
developed XML and XML-related technologies to meet this requirement.
Like anyy data being
g exchanged
g over a network,, XML communications
and transactions must be secured. In this respect, to maintain the
integrity of the transaction or communication, an XML document, just
like any other document or transaction, should be capable of
authentication and non-repudiation, and its content should remain intact
(integrity) and confidential.

XML Signature
XML is a very powerful, general-purpose meta-language used to enable
data interchange
g between diverse systems,
y
,p
platforms,, and international
languages. This robust, adaptable, easy-to-use data format can capture
both the structure and semantics of data making it possible to create a
wide variety of new Web applications.
Like HTML, XML uses tags (words bracketed by < and >) and
attributes (of the form name="value") to help place structured data into
ASCII files. XML is different from HTML in that it is a meta-language (a
language for describing other languages) and therefore, does not define
specific
ifi tags
t
and
d attributes,
tt ib t
b t rather
but
th provides
id rules
l to
t define
d fi those
th
t
tags
and attributes.
XML makes it easy for diverse Web applications to interact with each
other because it provides a standard way to parse and interpret data.
XML-encoded data becomes its own self-contained database ( intelligent
data data that knows about itself).

20

XML Signature
From a technical point of view, XML is a syntax for describing the
semantics (meaning) and structure of data. The following fragment of
XML illustrates these features:
<cheque>
<payer type="person">
<name>Wally Road</name>
<address>123 Billings Gate</address>
<email>wally@entrust.com</email>
</payer>
</cheque>
The
Th tags
t
enveloping
l i XML data
d t define
d fi the
th semantics
ti off the
th data.
d t In
I the
th
example, the string "Wally Road" is identified as the name of a person
who will be paying something. The tag preceding the data is called the
start tag; the tag following the data is called the end tag.
A start tag and its corresponding end tag define an XML element.
In the example, <name>Wally Road</name> is an element.

XML Signature
W3C and IETF are elaborate the standard format and functions for
XML signing;
g
is a XML data structure wich containes
The XML signature
the signature value and
the data necessary in the verification process;

The XML signature makes the following fonctions :

represent the digital signature of documents (XML or non XML) in
a XML format;
3 types of digital signature :
- the signature encapsulates the data being signed (enveloppe)
- the object to be signed can have the XML Signature embedded
within itself (enveloppante)
- the object to be signed can be separate from the XML Signature,
but reside within the same resource as the signature (dtache)

it uses pointers for selection the document zones to be included in

signature process;
permits URL references for documents.

21

XML Signature Structure

XML Signature Types

22

XML Signature Creation

1. Determine the resources to be signed.
2. Calculate the digest
g
of each resource. In XML Signatures,
g
, each
reference is specifed by a <Reference> element and its digest is placed
in a <DigestValue> child element.
3. Collect the <Reference> elements (with their associated digests) within
a <SignedInfo> element.
4. Calculate the digest of the <SignedInfo> element, sign the digest using
a valid private signature key, and put the signature value in a
<SignatureValue> element. Determine the resources to be signed.
5 If keying information is to be included,
5.
included place it in the <KeyInfo>
element.
6. Place the <SignedInfo>, <SignatureValue>, and <KeyInfo> elements
into the <Signature> element. The <Signature> element is the XML
Signature.

XML Signature Verification

1. Obtain the p
public key
y certificate,, either from <KeyInfo>
y
or from an
external source, and retrieve the public verification key.
2. Re-calculate the digest of the <SignedInfo> element. Use the public
verification key to verify that the value of the <SignatureValue> element
is correct when compared with the digest of the <SignedInfo> element.
3. If step 2 passes, re-calculate the digests on the related data objects of
the references contained within the <SignedInfo> element using
either the URI it contains, or by other means. Compare the calculated
digests with the digest values expressed in each <Reference>
element's corresponding <DigestValue> element.
4. If step 3 passes, validate the public verification certificate by finding a
certificate path to the trusted certificate (root of trust), such that this
path, and the certificates it contains, are valid.

23

HTML Signature
1. On client request (Get HTTP), a forms is preparing with
an applet and all are downloaded on client PC;
2. The applet is downloaded by JVM, after the code
signature verification;
3. The user fulfill the forms and request the signature; the
applet show a signature window;
4. By activation, the data are signed and are sended by
applet to the server; the format is S/MIME;
5. The HTTP server route the information on the security
server;
6. Using the public key of sender, the security server
verifies the signature by accessing the LDAP server;
7. The data are sended to the application server.

HTML Signature

24

Timestamping

PKI can enable new services between clients and

T t d Thi d
Trusted-Third
P ti
Parties
(TTP)
b
by
supporting
ti
confidentiality and mutual authentication;
Timestamp Servers- allow a client to prove at a later
date that some datum existed before a particular time
(ex. A signature was generated before a particular
time);
A protocol was recently completed by IETF PKIX
Working Group and become RFC 3161 in 2001Internet X.509 PKI Time Stamp Protocol (TSP);
TSP describes the format of a request sent to a Time
Stamping Authority (TSA) and the response returned;

Timestamping

Alice has a document and she wishes to obtain

a timestamp so that she can prove that it exists
at this point in time:
- Alice digitally signs the document;
- Alice sends the document hash and the signature to the TSA in
a TSP request;
- Alice sends the hash, not the document (the contents of
document remains secret)
- TSA authenticates Alice;
- TSA generates a signed response to Alice;
- Alice validates the digital signature and stores the response for
later use before a legal authority;

25

Timestamping

26