PKI Digital Certificates Explained

‫أكاديمية الحكومة اإللكترونية الفلسطينية‬
The Palestinian eGovernment Academy
www.egovacademy.ps

Tutorial 5: Information Security

Session 5
Certificates and Biometric Authentication

Dr. Mohammad Jubran
University of Birzeit
mjubran@birzeit.edu

PalGov © 2011 1

About

This tutorial is part of the PalGov project, funded by the TEMPUS IV program of the
Commission of the European Communities, grant agreement 511159-TEMPUS-1-
2010-1-PS-TEMPUS-JPHES. The project website: www.egovacademy.ps
Project Consortium:
Birzeit University, Palestine
University of Trento, Italy
(Coordinator )

Palestine Polytechnic University, Palestine Vrije Universiteit Brussel, Belgium

Palestine Technical University, Palestine
Université de Savoie, France

Ministry of Telecom and IT, Palestine
University of Namur, Belgium
Ministry of Interior, Palestine
TrueTrust, UK
Ministry of Local Government, Palestine

Coordinator:
Dr. Mustafa Jarrar
Birzeit University, P.O.Box 14- Birzeit, Palestine
Telfax:+972 2 2982935 mjarrar@birzeit.eduPalGov © 2011
2

© Copyright Notes
Everyone is encouraged to use this material, or part of it, but should properly
cite the project (logo and website), and the author of that part.

No part of this tutorial may be reproduced or modified in any form or by any
means, without prior written permission from the project, who have the full
copyrights on the material.

Attribution-NonCommercial-ShareAlike
CC-BY-NC-SA

This license lets others remix, tweak, and build upon your work non-
commercially, as long as they credit you and license their new creations
under the identical terms.

PalGov © 2011 3


Session 5: Certificates and Biometric
Authentication

Session 5 Outline:
• Session 5 ILO’s.
• PKI, X.509, and PGP
• SSL/TLS and IPSEC
• Biometric authentication and smart
cards.
PalGov © 2011 4

Tutorial 5: Session 5 ILOs

After completing this session you will be able to:
• B: Intellectual Skills
• b3: Design end-to-end secure and available systems.
• b4: Design integrity and confidentiality services.
• b5: Design user authentication and authorization services.

• D: Intellectual Skills
• d2: Systems configurations.
• d3: Analysis and identification skills.

PalGov © 2011 5


Authentication

Session 5 Outline:
• SSL/TLS
• IPSEC
• Biometric authentication.

PalGov © 2011 6

Public Key Infrastructure

• What is Public Key Infrastructure (PKI)

1) Set of hardware, software, people, policies, and
procedures needed to create, manage, distribute,
use, store, and revoke digital certificates[1]

2) Simply a system in which public keys are binded to
user identities by means of Certification Authority.

[1]: "LPKI - A Lightweight Public Key Infrastructure for the Mobile Environments", Proceedings of the 11th IEEE International
Conference on Communication Systems (IEEE ICCS'08), pp.162-166, Guangzhou, China, Nov. 2008.
PalGov © 2011 7

Digital Certificate

What is a digital certificate
• an electronic Id.
• allows a unique identification of an entity (using
private key)
• Must be provided by a trusted authority
• It is immune to being altered (data within can’t be
changed without detection), and so can be trusted.
• Binds the owners info. with its public key.
• Means of distributing public keys

PalGov © 2011 8

Digital Certificate continue

• What is the general layout of the digital certificate
– Owner’s distinguished name
– Owner’s public key
– Issuer’s distinguished name
– Issuer’s digital signature

• In a PKI, the CA is the issuer of digital certificates
• Different formats are being standardized (X.509,
PGP) with different digital certification contents.
• Digital certificates are being handled openly, and
so anyone can claim your identity. Wrong – this is
true only if he has my private key (the pair of the
public key within the certificate).
PalGov © 2011 9

Storage of Private Keys

• Private key proves the digital identity of
the sender and so must be kept secret,
how?
– Saved in an encrypted file, protected by a
password or PIN
– Encrypted and stored in hardware (smart
card, or USB stick) protected by a password
or PIN

PalGov © 2011 10

Digital Signature

Compare
Message
ed
Hash ge
a
ed mess
De cr yp t
Hash
ir hash Hash
Fixed length output
Key pa Fixed length output

Cipher Decipher
using private key using public key
l l l l
Digita Ori g i n a Digita Ori g i n a
re Text re Text
S ignatu S ignatu
Transfer
Combine Separate

PalGov © 2011 11

TRUST in the Signature

• Valid digital signature guarantee:
– Message integrity: message wasn’t changed
– Non-repudiation: the owner of the private key is the
sender.
• However, the identity of the sender can be
trusted if
– The private key is kept secret and only the owner of
the key can use it “private key storage”.
if anyone has access to the private key, he/she/it can replace the
owner
– The receiver is using the correct public key “public key
distribution”.
• if the receiver is using a wrong public key, the message integrity
might be assumed wrongly broken
• How to make sure of using the right public key? [ digital certificates]
PalGov © 2011 12

Certification Authorities

Certification authority (CA)
• generates a signed certificate using CA’s private key
which binds a particular entity to its public key.
• An entity responsible to issue, revoke and manage
digital certificates
– Verify the identity and information provided by the entity
asking for certificate
– may generate private and public keys for entities.
– binds the identity and associated info. of an entity with its
public key using the CA’s private key  public key
certificate
– Public key certificates are authentic as they can’t be altered
without detection.
PalGov © 2011 13

Certification Authorities continue

• Procedure to obtain a CA signed digital certificate:
– Submit a proof of identity and any other information to
be included in the certificate to CA (usually done offline)
– CA uses its private key to bind the provided information by
the entity to its public key
– Again, the asymmetric key pair might be generated by the
CA, or the public key is provided by the entity itself.
– Again, Certificate contains
• Owner’s distinguished name
• Owners public key
• Issuer’s distinguished name
• Issuer’s digital signature

PalGov © 2011 14

Certification Authorities continue

• How to validate a public key within a certificate:
– Get the CA signed certificate (from the entity itself or
elsewhere)
– The CA public key must be known for you.
– Use the CA public key to verify the signature within the
certificate. “notice: entity info and public key are binded by the CA
private key”
– If the signature is valid then accept the public key.
Digital Certificate of Jubran Use KCA to verify
· Some info. the binding
If Kj is truly binded
· Public key; Kj between Sj and Kj
to Sj then use it
· Siganture; Sj

CA public key KCA

PalGov © 2011 15

Certification Authority continue

• Important: you must TRUST the CA in order to
TRUST the digital certificate including the public
key signed by it, and so any digitally signed
messages validated using this public key

PalGov © 2011 16

Public Key Distribution

In PKI, Public keys must be available
• Package them into a digital certificate
– Digitally sign the key and owner’s identity into a public
key certificate
• Three ways to distribute certificates and hence
public keys
– Exchanging certificates personally (could be
electronically)
– Receive it from a trusted person (trusted introducer)
– Get a certified key from a public repository

PalGov © 2011 17

Digital Certificate Formats
Lecture Notes of David Chadwick

• X.509 format
– widely accepted international standard format used by
Microsoft, Verisign etc.
– Used by S/MIME email
– Signed by a single Certification Authority that has a
globally unique name
– A CA issues certificates to its users and to subordinate
CAs
– trust can be built up for whole domains of people –
flexible and allow scalability

PalGov © 2011 18

Digital Certificate Formats

• PGP format
– allows multiple owner identities for a key
– allows multiple certifiers (CAs) for a key
– user certifies his own key
– anyone else can also be a certifier
• a user or a CA
– user issues his own self signed certificate, and anyone
else may choose to certify it.
– people build up trust networks between themselves, in a
1-to-1 fashion – less scalable than X.509

PalGov © 2011 19

X.509 Certificate Contents

X.509 Digital certificates contents
• Serial Number: uniquely identify the certificate.
• Subject: The person, or entity identified.
• Signature Algorithm: The algorithm used to create the signature.
• Signature: The actual signature to verify that it came from the issuer.
• Issuer: The entity that verified the information and issued the
certificate.
• Valid-From: The date the certificate is first valid from.
• Valid-To: The expiration date.
• Key-Usage: Purpose of the public key (e.g. encipherment, signature,
certificate signing...).
• Public Key: The public key.
• Thumbprint Algorithm: The algorithm used to hash the public key.
• Thumbprint: The hash itself, used as an abbreviated form of the
public key.
PalGov © 2011 20

X.509 Certificate

X.509 Digital certificates
displayed in Microsoft
explorer for the
management
educational system
(ritaj) at Birzeit
University

PalGov © 2011 21

X.509 Certificate continue explorer for the management
educational system (ritaj) at
Birzeit University

PalGov © 2011 22

PGP Certificate Contents

PGP Digital certificates contents (but is not limited to)
• The PGP version number
• The certificate holder's public key — the public portion of your key
pair, together with the algorithm of the key
• The certificate holder's information — this consists of "identity"
information about the user, such as his or her name, user ID,
photograph, and so on.
• The digital signature of the certificate owner — also called a self-
signature, this is the signature using the corresponding private key of
the public key associated with the certificate.
• The certificate's validity period — the certificate's start date/ time
and expiration date/ time; indicates when the certificate will expire.
• The preferred symmetric encryption algorithmfor the key —
indicates the encryption algorithm to which the certificate owner
prefers to have information encrypted. The supported algorithms are
CAST, IDEA or Triple-DES.
PalGov © 2011 23

Self signed public key certificates

• In a self signed certificate the owner signs his
own public key using his private key.
– the certificate will be resistive to change
– but the info within is not evaluated and unsigned by other
than the owner himself
– doesn’t help in building trusts
– is necessary to start the trust hierarchy – root CA
– Can’t be revoked, by other than the owner
– must be obtained in a trustworthy manner and be kept
securely
– used for distributing X.509 root CA keys
– used for distributing user’s PGP keys

PalGov © 2011 24

Certificate from http://en.wikipedia.org/wiki/X.509

Is this X.509 certificate a self signed certificate?
Certificate: Data: Version: 1 (0x0)
Serial Number: 7829 (0x1e95)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division, CN=Thawte Server CA/emailAddress=server-
certs@thawte.com
Validity
Not Before: Jul 9 16:04:02 1998 GMT
Not After : Jul 9 16:04:02 1999 GMT
Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala, OU=FreeSoft,
CN=www.freesoft.org/emailAddress=baccala@freesoft.org
Subject Public Key Info: Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit): 00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb: ……. shortened
Exponent: 65537 (0x10001)
93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d: ……. shortened
PalGov © 2011 25


Certificate: Data: Version: 1 (0x0)
Serial Number: 7829 (0x1e95)
certs@thawte.com
Validity
No, because
these are not
Not Before: Jul 9 16:04:02 1998 GMT
the same
Not After : Jul 9 16:04:02 1999 GMT
Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala, OU=FreeSoft,
CN=www.freesoft.org/emailAddress=baccala@freesoft.org
Modulus (1024 bit): 00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb: ……. shortened
Exponent: 65537 (0x10001)
93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d: ……. shortened
PalGov © 2011 26


Version: 3 (0x2)
Serial Number: 1 (0x1)
certs@thawte.com
Sure
Validity
Not Before: Aug 1 00:00:00 1996 GMT
Not After : Dec 31 23:59:59 2020 GMT
Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
certs@thawte.com
Modulus (1024 bit): 00:d3:a4:50:6e:c8:ff:56:6b:e6:cf:5d:b6:ea:0c: ….. Shortened
Exponent: 65537 (0x10001)
X509v3 extensions: X509v3
Basic Constraints: critical
CA:TRUE, Signature Algorithm: md5WithRSAEncryption …. Shortened
PalGov © 2011 27

Moving X.509 Certificates and key pairs between
applications

• X.509 Digital
certificates
export wizard as
being displayed moving public key certificates
in Microsoft (and certificate chains to the
root CA) between applications
explorer for the
management
educational
system (ritaj) at
Birzeit University

encrypted and protected by
a user provided Pass Word

PalGov © 2011 28

Trust in a single CA’s PKI

CA’s domain of trust: certificates of all users in this domain were signed by
this CA (MTIT) – hence users trust each other based on their trust of the CA

Certificates and Trust
• Ahmad private key and certificate
• MTIT self signed certificate (used to MTIT
sign Ahmad’s certificate) Ahmad
CA
Certificates and Trust
• Remma private key and certificate Reema
• MTIT self signed certificate (used to
sign Reema’s certificate)

In a personal security environment (by yourself using PC), both Ahmad
and Reema should trust (trust the info in the digital certificates and any
digitally signed document) each other depending on the digital certificates
exchanged between them, (private keys will be used during the
communication) because they belong to the same CA domain (MTIT)
PalGov © 2011 29

Cross Certification

CA’s domain of trust: certificates CA’s domain of trust: certificates
of all users in this domain were of all users in this domain were
signed by this CA (MoI) signed by this CA (MTIT)

Cross
MoI root CA Certification MTIT root CA
Ahmad Reema

Certificates and Trust Certificates and Trust
• Ahmad private key and certificate • Remma private key and certificate
• MoI self signed certificate (used to • MTIT self signed certificate (used
sign Ahmad’s certificate) to sign Reema’s certificate)

Cross certification is when relation of trust is built between the CAs,
achieved when one signs the public key of the other (one-way or mutual)
PalGov © 2011 30

Trust in a single CA’s PKI

Bridge
CA

MoI BZU
Root CA
MTIT Root CA

Ahmad
Root CA
User 1
Reema

The problem with cross certification is that every (root) CA has to have a pair
wise trust relationship with every other (root) CA that it trusts.

The solution is to have a Bridge CA. Now a (root) CA only needs to have a
trust relationship with the Bridge CA and then certification paths can be
constructed with every other (root) CA that is also cross certified by the Bride.
PalGov © 2011 31

Certification Path

• Hierarchy of trust starts by the root CA and
ends with the sender certificate.
– The root CA self sign its certificate
– Next certificate is signed by the private key of the root CA
– List continue to the sender, its certificate is signed by the
private key of the one step higher CA.
• Each certificate in the path contains the
public key of the next CA

PalGov © 2011 32

Certification Path explorer for the educational
management system (ritaj) at
Birzeit University

PalGov © 2011 33

Certification Path explorer for the educational
management system (ritaj) at
Birzeit University

Root CA (VeriSign),
self signed certificate

PalGov © 2011 34

Certification Path explorer for the web mail
system at Birzeit University

Root CA (Mail CA),
self signed certificate

PalGov © 2011 35

Certificate Issuance within a CA Hierarchy

CA’s domain of trust: certificates of all users and CAs in this domain were signed
by this CA (MTIT) – hence users trust each other based on their trust of the CA

MTIT CA

MoI CA

BZU CA

Reema

Ahmad

Ahmad and Reema trust each other because their certificates path meet
somewhere, not necessarily at root
PalGov © 2011 36

Different trust scenarios

CA’s domain of trust: certificates of all users and CAs in this domain were signed
by this CA (MTIT) – hence users trust each other based on their trust of the CA

User 1 MTIT CA

MoI CA

CA1 BZU CA

Reema

User 2 Ahmad

• User 1 won’t be trusted by Ahmad and Reema as he has only a self signed certificate
• User 2 won’t be trusted by Ahmad and Reema as CA1 is not trusted by any CA in the
certification path of Ahamad and Reema (assuming not cross certification)
PalGov © 2011 37

View certificates stored in my browser (CAs I trust)

• Open Internet Explorer
• Click on the Tools
menu
• From the drop down list
select Internet Options
• Click the Content tab
• Click the Certificates
button

PalGov © 2011 38

Which CA deserves my trust?
Some text is obtained from rfc2527

• To which CA should I register?
• Should I trust a certificate signed by this CA?
• Certificate Policies (CP)
– set of rules that indicates the applicability of a certificate to a particular
community and/or class of application with common security requirements.
– it may be used by a certificate user to help in deciding whether a
certificate, and the binding therein, is sufficiently trustworthy for a
particular application.
• Certification Practise Statements (CPS)
– is a statement of the practices which a certification authority employs in
issuing.
– detailed description of the practices followed by a CA in issuing and
otherwise managing certificates may be contained in it.
• The better its practices and procedures, the more trustworthy
the CA

PalGov © 2011 39

Which CA deserves my trust? continue

• VeriSign® Trust Network Certificate Policy

http://www.digitalsign.pt/ECDIGITALSIGN/cps/VRSN_2.8.3.pdf

• Symantec Trust Network Certification Practice
Statement (CPS)

http://www.verisign.com/repository/CPS/

PalGov © 2011 40

Certificate Revocation

• Why need to revoke certificates?
– Certificates associated with stolen private key.
– You forgot the phrase used to generate your private key.
– You need to use new private key.
– User’s privilege is no more valid.
– Left the company
– ... Many other reasons

• Don’t trust a signed message from a revoked certificate.
• If trust to a root CA fails, it must be removed from the trust
store (depends on the application)
• Any certificate of a CA in the hierarchical certification path
can be revoked by the certifying CA, similar to a user’s
certificate. The same apply in any model of CA certify
another CA including the case of cross certification.
PalGov © 2011 41

Certificate Revocation continue

• In X.509,
– list of revoked certificates is held in a Certificate
Revocation List (CRL)
– CA must revoke the certificates it has issued
– Revocation can be requested by the user, the CA
administrator, or other trusted entity
• In PGP,
– each public key or signature on a key can be revoked
– key signers can revoke their individual signatures on a
public key
– In new versions of PGP you must generate a key
revocation certificate while you know the private key, save
it in a safe place, and then use it to revoke certificate if
private key is lost.

PalGov © 2011 42

Distribution of Revocation Information

• X.509 - CRLs are published and distributed in the same
way as the certificates, and by storing in LDAP
directories and on Web pages but it is the responsibility
of the relying party to fetch the CRL.

• X.509 PKIX group has defined an Online Certificate
Status Protocol so that a relying party can query an
OCSP server to see if a certificate is valid. This is
similar to how credit cards are checked by shopkeepers
today.

• PGP - key signers and key owners should send their
revoked signatures to key servers and to their PGP
friends

PalGov © 2011 43

Highly Secure Certificates
http://www.cabforum.org/certificates.html

Extended Validation SSL Certificates
• It is intended to provide an improved level of authentication of
entities that request digital certificates for securing transactions on
their Web sites.
• The next generation of Internet browsers will display EV SSL-
secured Web sites in a way that allows visitors to instantly
ascertain that a given site is indeed secure and can be trusted.
• A new vetting format, which all issuing Certification Authorities
(CAs) must comply with, ensures a uniform standard for certificate
issuance. This means that all CAs must adhere to the same high
security standards when processing certificate requests.
• Visitors to EV SSL-secured Web sites can trust that the
organization that operates the site has undergone and passed the
rigorous EV SSL authentication process as defined by the
CA/Browser Forum.
PalGov © 2011 44


Authentication

Session 5 Outline:
• SSL/TLS
• IPSEC
• Biometric authentication.

PalGov © 2011 45

Secure Socket Layer/Transport Layer Security
(SSL/TLS)
• Main purpose is to provide a secure (authentication,
confidentiality, and data integrity) web traffic between client
(web browser) and server (website server).
• Achieved through, digital signatures, certificates, and
cryptography.
• Historical overview:
– Earlier versions of SSL (SSLv1 and SSLv2) were invented by
Netscape, both suffer from serious security weaknesses.
– In 1996, SSLv3 was published, to make it available to all and
get the help of others in finding bugs within the protocol, the
publisher tried to make it an open source. However, protocol
uses the RSA cryptography algorithm which had a patent, and
so the SSLv3 can’t be open source.
– Transport Layer Security (TLS), the Internet Standard
variation of SSL was published in 1999, very similar to SSLv3
but incompatibility.
PalGov © 2011 46

SSL/TLS continue

• SSL sessions run over TCP/IP connections
• SSL session can be used by multiple TCP/IP connections
– In parallel (more than one connection use the same SSL session
– Sequential, after one connection terminate, a new connection can
use the same SSL session
– All depends on the SSL session ID (will be discussed later)
• A client and server can disconnect then reconnect and
continue using the same SSL session.
client server
Application Application
SSL SSL
TCP TCP
IP IP

Internet
PalGov © 2011 47

How SSL works
• Birzeit wanted to secure their website, so they need to
obtain a digital certificate from a trusted CA.
– Birzeit admin will generate a Certificate Signing Request (CSR),
exact procedure depends on the http server – in this process a
private key and public key (within CSR) will be produced.
– An application including the CSR will be submitted to a trusted CA to
get a digitally signed certificate by the CA.
– The CA will investigate the information provided by Birzeit (their
domain, legal documents to prove the identity of birzeit, ... “this
depends on the CA policies”).
– If validation successfully completed, the CA will create a digital
certificate signed using its private key for Birzeit web server.
– Birzeit admin will install the certificate on its web server.
– Now, connections to the web site will be though a secure
connections.

PalGov © 2011 48

How SSL works continue
• A client wanted to access the secure Birzeit website through his
web browser (SSL Handshake)
– Client send a Client Hello message to server (Phase 1)
• Session ID (set to zeros initially)
• Supported SSL versions
• Supported algorithms
• Some data to avoid reusing this packet by others (replay), a time stamp
and random number
– Server replies with a Server Hello message to client(Phase 1)
• Session ID (saved to be used incase the TCP/IP connection is broken)
• The SSL version to be used (most secure, latest version)
• The algorithms to be used
• Some data to avoid reusing this packet by others (time stamp and a
random number)
– Server sends the following to the client (Phase 2)
• Server certificate chain up to the root CA (hopefully obtained from a
trusted CA)
• Optional: Server Key Exchange
• Optional: Server requests client’s certificate
• Server Hello Done
PalGov © 2011 49

• A client wanted to access the secure Birzeit website
through his web browser
– Client send a Client Hello message to server (Phase 1)
– Server replies with a Server Hello message to client (Phase 1)
– Server sends the following to the client (Phase 2)
– Client reply with the following to the server (Phase 3)
• Client certificate (optional)
• Client key exchange
• Certificate verification (optional)
• pre-master keys are now derived and exchanged
– Client send the following to the server (Phase 4)
• Change Cipher Specifications
• Finished
– Server reply with the following to the client (Phase 4)
• Finished
– SSL Handshake is now complete and both will use the agreed
crypto algorithm and key while exchanging data.
PalGov © 2011 50

Client Server

Client Hello

Server Hello
Server Certificate
Server Key Exchange
Certificate Request
Server Hello Done
Client Certificate
Client Key Exchange
Certificate Verification
Change Cipher Spec
Finished

Change Cipher Spec
Finished

Secure Data Transfer
PalGov © 2011 51

SSL Handshake for Resumed Sessions

• What will happen if the TCP connection is broken, shall I
redo the SSL handshaking
– Nope
– In the initial client Hello message, set the session id equal to that
of the broken session.
– Server replies with a Server Hello message to client
– Server send the following to the client
• Finished
– Client reply the following to the server
• Finished
– SSL Handshake is now complete and TCP will be over SSL.

PalGov © 2011 52

SSL Alert Protocol Lecture Notes of David Chadwick

The SSL Alert Protocol Message
• Used to convey alerts and errors to the peer
• The alert messages are protected according to the ciphers
agreed for the SSL session
• Each message consist of two bytes
– The first byte indicates the severity of the message
1. Warning
2. fatal
• If the level is fatal SSL terminates the connection
– The second byte contains the code that indicates the specific type
of alert

PalGov © 2011 53

Key derivation in SSL Lecture Notes of David Chadwick

The pre-master secret from Phase 3 is concatenated with the
client and server random numbers to provide a master secret,
which is then hashed to produce

• A shared key for message MACs created by the client
• A shared key for message MACs created by the server
• A symmetric encryption key for messages sent by the client
• A symmetric encryption key for messages sent by the server

The reason the client and server use different keys is to make it
more difficult to break the messages, and to know who the
messages have come from

PalGov © 2011 54

SSL deficiencies Lecture Notes of David Chadwick

• User authentication is not available in v2 and is only optional
in v3
– Web based CAs don’t always authenticate the user strongly e.g.
Verisign Class 1, so the server can’t trust the user’s certificate anyway
• Poor support for certificate revocation in SSL products
– Most web clients would not know if a server’s certificate had been
revoked
• If you configure you system poorly, it is possible for SSL to
negotiate a NULL cipher suite so that no protection is carried
out at all
• The cost of SSL certificates varies considerably, from under $100 to over
$1000. The latest prices can be obtained from
http://www.sslreview.com/content/pricing.html

PalGov © 2011 55

SSL Record
The SSL or TLS messages exchanged between the two parties
are called records. Which have the following basic format
• type field: indicates the record type as a handshake or data,
• version field: indicated the SSL or TLS version used,
• length field: indicated the length of the record
• Data fields: contain the upper layer data
• Mac field: contains the data MAC.
• The data and MAC field contain encrypted data and
encrypted MAC using the receiver’s data encryption key.
• It’s worth mentioning that MACs are not always used
“optional”.

TYPE VERSION LENGTH DATA MAC

PalGov © 2011 56

IP Security (IPSec)
• Virtual Private Networks (VPNs) provide a secure
communication (path) through an untrusted network (Internet).
• VPNs are usually used to connect separated INTRANETS
through the Internet. MTIT

Firewall Internet
el
Tunn
Firewall

BZU

• VPNs allow a secure connection for remote users or offices to
a central network
• VPNs are usually achieved through:
– Authentication
– Encryption
– Compression
– Tunneling PalGov © 2011 58

IPSec continue
• Tunneling: is achieved by encapsulating the packets header and
the payload of a protocol inside the payload of another protocol.

• Now if the payload of the new protocol is encrypted using a secret
key (known only for sender and receiver), then the untrusted
network can't figure out the original data and protocol, hence
transmission is secure.

• VPNs usually uses IPSec to create encrypted tunnels.

• IPSec works in the network layer (OSI model) and provides
– Encryption
– Authentication
– Compression “using the IP Payload Compression Protocol - used only if
really compress the payload, otherwise the data is sent uncompressed.”

PalGov © 2011 59

IPSec continue
• To implement IPSec two protocols were introduced:
– Authentication Header (AH)
• Authenticate both header and payload
• Besides authentication, provides anti-replay and integrity
• Doesn’t encrypt payload (no confidentiality)
• Not recommended
– Encapsulating Security Payload (ESP)
• Authenticate both header and payload (MAC)
• Besides authentication, provides anti-replay, integrity, and confidentiality.
• Preferred to establish VPN in an IPSec Tunnel Mode

ESP Encrypted Orig IP Header and ESP
IP “SPI, Payload “Transport and Application Layer Trailer MAC
Header Seq #” Data and Protocol” padding … ”

PalGov © 2011 60

IPSec continue
• Use strong encryption for the original IP header and payload using a
shared keys
– Manually configured on firewalls.
– Automatically shared using Internet Key Exchange Protocol (IKE Protocol)
• Message Authentication Code (MAC) is used for packet authentication
(original message hash concatenated with a shared secret – SHA-1 or
MD5).
• The packet will be routed through the internet using the outer IP header (IP
of the firewall or external device to operate the ESP).
• Since many device in the Intranet may utilize the IPSec Protocol, then a
session identifier must be defined; which is set in the ESP field which
includes
– Security Parameter Index (SPI): uniqly determine the Security Association
(SA, will be defined next) to which the datagram belongs.
– Sequence number field: to protect against replay attacks.
ESP Encrypted Orig IP Header and ESP
IP “SPI, Payload “Transport and Application Layer Trailer MAC
Header Seq #” Data and Protocol” padding … ”

PalGov © 2011 61

IPSec continue
• Internet Key Exchange Protocol (IKE Protocol)
– Communicating devices must agree on a shared secrets (keys
and protocols to be used)
– IPSec is a key management tool used to negotiate, create, and
manage Security Association (SA)
– SA defines:
• IPSec Encryption algorithms (DES, 3DES, CAST, RC5, IDEA, Blowfish,
and AES)
• IPSec Integrity algorithms (HMAC-SHA-1, HMAC-MD5)
• IPSec Authentication (Digital Signatures with RSA, Public Key Encryption
“encrypts using owns private key and decrypts using others private key”
• IPSec shared session Keys (Diffe-Helman)

PalGov © 2011 62

IPSec continue
• IPSec Authentication
Secret
Message
Value

HMAC

MAC: 128 bits

– Secret value is used to provide data integrity and is only known for
communicating devices.
– Hash-based Message Authentication Code (HMAC): an algorithm
used to calculate a message authentication code (MAC) involving a
cryptographic hash function in combination with a secret key.

– C

PalGov © 2011 63

Biometric Authentication Extracted from [1],[2]

• Biometrics: Any human physiological or behavioral which has the following
desirable properties
– Universality: which means that every person should have the characteristic
– Uniqueness: which indicates that no two persons should be the same in terms
of the characteristic.
– Permanence: which means that the characteristic should be invariant with time.
– Collectability: which indicates that the characteristic can be measured
quantitatively.
– Performance: which refers to
• achievable identification accuracy
• resource requirements to achieve an acceptable identification accuracy
• working or environmental factors that affect the identification accuracy
– Acceptability: which indicates to what extent people are willing to accept the
biometric system
– Circumvention: which refers to how easy it is to fool the system by fraudulent
[1] R. Clarke, “Human identification in information systems: Management challenges and public policy issues,” Information Techn ology &
People, Vol. 7, No. 4, pp. 6-37, 1994.
[2] E. Newham, The Biometric Report. http://www.sjb.com/: SJB Services, New York, 1995

PalGov © 2011 65

Biometric Authentication continue

Biometrics Universality Uniqueness Permanence Collectability Performance Acceptability Circumvention

Face H L M H L H L
Fingerprint M H H M H M H
Hand
Geometry
M M M H M M M
Keystrokes L L L M L M M
Hand Vein M M M M M M H
Iris H H H M H L H
Retinal Scan H H M L H L H
Signature L L L H L H L
Voice Print M L L M L H L
DNA H H H L H L L
Ear M M H M M H M
• H: High, M:Medium, L:Low
• Tabulated values from INTRODUCTION TO BIOMETRICS,Anil Jain,Michigan State University

PalGov © 2011 66

Biometric Authentication continue www.biometrics.gov

• Biometrics are being tested for the following purposes:
– Recognition is a generic term, and does not necessarily imply either
verification or identification. All biometric systems perform
“recognition” to “again know” a person who has been previously
enrolled.
– Verification is a task where the biometric system attempts to confirm
an individual’s claimed identity by comparing a submitted sample to
one or more previously enrolled templates.
– Identification is a task where the biometric system attempts to
determine the identity of an individual. A biometric is collected and
compared to all the templates in a database. Identification is
• closed-set: if the person is known to exist in the database.
• open-set or watchlist: if the person is not guaranteed to exist in the database.
The system must determine whether the person is in the database.

PalGov © 2011 67

Biometric System Operation

Enrollment Process Identification Verification
User
User User

Sensor Sensor Sensor
Biometrics Biometrics Biometrics
extraction extraction extraction

Processing Processing
Processing Features extraction
Features extraction Features extraction

Identity Matching
Search through
Template is sore in Database Accept /
Database Identity
Reject

Identified /
Unidentified Database

PalGov © 2011 68

Biometric System Operation continue
• In Identification and Verification systems, some statistical
parameters determine the quality of the biometrics systems
quality:
– True Accept Rate: the percentage of times a system (correctly) verifies a
true claim of identity.
– True Reject Rate: the percentage of times a system (correctly) rejects a
false claim of identity.
– False Accept Rate: the percentage of times a system produces a false
accept, which occurs when an individual is incorrectly matched to another
individual’s existing biometric
– False Alarm Rate: the percentage of times an alarm is incorrectly sounded
on an individual who is not in the biometric system’s database, or an alarm
is sounded but the wrong person is identified (used in open-set
identification)
– Type I Error: An error that occurs in a statistical test when a true claim is
(incorrectly) rejected.
– Type II Error: An error that occurs in a statistical test when a false claim is
(incorrectly) accepted.

PalGov © 2011 69

Biometric System Operation continue
Lecture slides by Lawrie Brown

Choosing this is very
critical in biometrics

PalGov © 2011 70

Attacks on Biometric Systems

Verification
1. Spoofing: a fake biometric is presented at the
sensor. User

2. Sensor Bypass: illegally intercepted data is
resubmitted (replay) Sensor
3. Overriding feature extraction: feature detector is Biometrics 1
replaced by a Trojan horse program to produces extraction 2
feature sets chosen by the attacker.
Processing 3
4. Tampering with feature representation: legitimate Features extraction
features are replaced with a synthetic feature set 4
5. Corrupting the matcher: matcher is replaced by a
5 Matching
Trojan horse program to produce scores chosen 8
by the attacker Accept /
Identity
6. Unauthorized access to stored templates Reject
7
7. Corruption of template fetching
8. Decision override 6 Database

PalGov © 2011 71

Attacks countermeasures for Biometric
Systems
• Identify and prioritize threats:
– RISK=OCCURANCE_LIKLIHOOD X CONSEQUECE_SEVERITY
– Attack occurrence likelihood related to cost and complexity
• Countermeasures:
– Maturity, cost and effectiveness.
– Prioritized implementation of countermeasures.
• Methodology requires system level analysis.
– Common needs.

PalGov © 2011 72

Biometrics and Cryptography

• In biometrics systems the integrity of data
transmission must be secure all the way from the
sensor to the application. This is typically achieved by
cryptographic methods.

• The enhancement of security level in biometrics-
based systems can be done in two ways:
– use of encryption keys to protect biometric information
(for authentication purposes)
– use of biometric mechanisms to secure the privacy of
encryption keys and access to data

PalGov © 2011 73

Summary

• In this session we discussed the following:
– PKI, X.509, and PGP
– SSL/TLS
– IPSec
– Biometric authentication.
– Biometric systems are vulnerable to a number of attacks
– Solutions to these attacks exist, but there is still room for
improvement.

PalGov © 2011 74

PKI Digital Certificates Explained

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (9)

Ähnlich wie PKI Digital Certificates Explained

Ähnlich wie PKI Digital Certificates Explained (20)

Mehr von Mustafa Jarrar

Mehr von Mustafa Jarrar (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

PKI Digital Certificates Explained