E gov security_tut_session_5

1PalGov © 2011

أكاديمية الحكومة اإللكترونية الفلسطينية

The Palestinian eGovernment Academy

www.egovacademy.ps

Dr. Mohammad Jubran

University of Birzeit

[email protected]

Tutorial 5: Information Security

Session 5

Certificates and Biometric Authentication

mailto:[email protected]

2PalGov © 2011

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

University of Trento, Italy

University of Namur, Belgium

Vrije Universiteit Brussel, Belgium

TrueTrust, UK

Birzeit University, Palestine

(Coordinator )

Palestine Polytechnic University, Palestine

Palestine Technical University, PalestineUniversité de Savoie, France

Ministry of Local Government, Palestine

Ministry of Telecom and IT, Palestine

Ministry of Interior, Palestine

Project Consortium:

Coordinator:

Dr. Mustafa Jarrar

Birzeit University, P.O.Box 14- Birzeit, Palestine

Telfax:+972 2 2982935 [email protected]

http://www.egovacademy.ps/

3PalGov © 2011

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

4PalGov © 2011


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.

5PalGov © 2011

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.

6PalGov © 2011



Authentication

Session 5 Outline:



• SSL/TLS

• IPSEC

• Biometric authentication.

7PalGov © 2011

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.

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4737164




8PalGov © 2011

Digital Certificate

What is a digital certificate

• an electronic Id.

• allows a unique identification of an entity (usingprivate 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

9PalGov © 2011

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

10PalGov © 2011

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

11PalGov © 2011

Digital Signature

Message

Hash

Fixed length output

Cipherusing private key

Combine

Digital

Signature

Original

Text

Hash

Fixed length output

Decipherusing public key

Separate

Digital

Signature

Original

Text

Decrypted

hash

Hashed

message

Compare

Transfer

Key pair

12PalGov © 2011

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]

13PalGov © 2011

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.

14PalGov © 2011

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

15PalGov © 2011

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

· Some info.

· Public key; Kj

· Siganture; Sj

CA public key KCA

Use KCA to verify

the binding

between Sj and Kj

If Kj is truly binded

to Sj then use it

16PalGov © 2011

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

17PalGov © 2011

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

18PalGov © 2011

Digital Certificate Formats

• 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

Lecture Notes of David Chadwick

19PalGov © 2011

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


20PalGov © 2011

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.

http://en.wikipedia.org/wiki/Hash

21PalGov © 2011

X.509 Certificate

X.509 Digital certificates

displayed in Microsoft

explorer for the

management

educational system

(ritaj) at Birzeit

University

22PalGov © 2011

X.509 Certificate continue



explorer for the management

educational system (ritaj) at

Birzeit University

23PalGov © 2011

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.

24PalGov © 2011

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

25PalGov © 2011


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-

[email protected]

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/[email protected]

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

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

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


26PalGov © 2011


Is this X.509 certificate a self signed certificate? Certificate: Data: Version: 1 (0x0)

Serial Number: 7829 (0x1e95)


Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,

OU=Certification Services Division, CN=Thawte Server CA/emailAddress=server-

[email protected]

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/[email protected]



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

No, because

these are not

the same




27PalGov © 2011


Is this X.509 certificate a self signed certificate? Version: 3 (0x2)

Serial Number: 1 (0x1)


Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Server CA/[email protected]

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, OU=Certification Services Division, CN=Thawte Server CA/[email protected]



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

Sure




28PalGov © 2011

Moving X.509 Certificates and key pairs between

applications

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

encrypted and protected by a user provided Pass Word

moving public key certificates (and certificate chains to the

root CA) between applications

29PalGov © 2011

Trust in a single CA’s PKI

MTIT

CA

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

Ahmad

Reema

Certificates and Trust• Remma private key and certificate

• MTIT self signed certificate (used to

sign Reema’s certificate)

Certificates and Trust• Ahmad private key and certificate

• MTIT self signed certificate (used to

sign Ahmad’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)

30PalGov © 2011

Cross Certification

MTIT root CA

CA’s domain of trust: certificates

of all users in this domain were

signed by this CA (MTIT)

Ahmad Reema

Certificates and Trust• Remma private key and certificate

• MTIT self signed certificate (used

to sign Reema’s certificate)

Certificates and Trust• Ahmad private key and certificate

• MoI self signed certificate (used to

sign Ahmad’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)

MoI root CA

CA’s domain of trust: certificates

of all users in this domain were

signed by this CA (MoI)

Cross

Certification

31PalGov © 2011

Trust in a single CA’s PKI

MTITRoot CA

Ahmad

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.

MoIRoot CA

BZURoot CA

User 1

Bridge

CA

32PalGov © 2011

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

33PalGov © 2011

Certification Path



explorer for the educational

management system (ritaj) at

Birzeit University

34PalGov © 2011

Certification Path



explorer for the educational

management system (ritaj) at

Birzeit University

Root CA (VeriSign),

self signed certificate

35PalGov © 2011

Certification Path

Root CA (Mail CA),

self signed certificate



explorer for the web mail

system at Birzeit University

36PalGov © 2011

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

Reema

Ahmad

MoI CA

BZU CA

Ahmad and Reema trust each other because their certificates path meet

somewhere, not necessarily at root

37PalGov © 2011

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

MTIT CA

Reema

Ahmad

MoI CA

BZU CA

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

User 1

User 2

CA1

38PalGov © 2011

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

39PalGov © 2011

Which CA deserves my trust?

• 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

Some text is obtained from rfc2527

40PalGov © 2011

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/

41PalGov © 2011

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.

42PalGov © 2011

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.

43PalGov © 2011

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


44PalGov © 2011

Highly Secure Certificates

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.

http://www.cabforum.org/certificates.html

45PalGov © 2011



Authentication

Session 5 Outline:



• SSL/TLS

• IPSEC

• Biometric authentication.

46PalGov © 2011

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

Secure Socket Layer/Transport Layer Security

(SSL/TLS)

47PalGov © 2011

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

SSL/TLS continue

Application

SSL

TCP

IP

Application

SSL

TCP

IP

Internet

client server

48PalGov © 2011

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

How SSL works

49PalGov © 2011

• 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

How SSL works continue

50PalGov © 2011

• 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)• Change Cipher Specifications

• Finished

– SSL Handshake is now complete and both will use the agreed crypto algorithm and key while exchanging data.


51PalGov © 2011


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

Secure Data Transfer

Client Server

Change Cipher Spec

Finished

52PalGov © 2011

• 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

• Change Cipher Specifications

• Finished

– Client reply the following to the server

• Change Cipher Specifications

• Finished

– SSL Handshake is now complete and TCP will be over SSL.

SSL Handshake for Resumed Sessions

53PalGov © 2011

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

SSL Alert ProtocolLecture Notes of David Chadwick

54PalGov © 2011

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

Key derivation in SSLLecture Notes of David Chadwick

55PalGov © 2011

• 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

SSL deficienciesLecture Notes of David Chadwick

56PalGov © 2011

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

SSL Record

57PalGov © 2011



Authentication

Session 5 Outline:



• SSL/TLS

• IPSEC

• Biometric authentication

58PalGov © 2011

MTIT

BZU

Internet

Firewall

Firewall

Tunnel

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

• VPNs allow a secure connection for remote users or offices to

a central network

• VPNs are usually achieved through:

– Authentication

– Encryption

– Compression

– Tunneling

IP Security (IPSec)

59PalGov © 2011

• 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.”

IPSec continue

60PalGov © 2011

• 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

IPSec continue

IP

Header

ESP“SPI,

Seq #”

Encrypted Orig IP Header and

Payload “Transport and Application Layer

Data and Protocol”

ESP

Trailer

padding … ”

MAC

61PalGov © 2011

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

IPSec continue

IP

Header

ESP“SPI,

Seq #”

Encrypted Orig IP Header and

Payload “Transport and Application Layer

Data and Protocol”

ESP

Trailer

padding … ”

MAC

62PalGov © 2011

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

IPSec continue

63PalGov © 2011

• IPSec Authentication

– 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

IPSec continue

Secret

ValueMessage

HMAC

MAC: 128 bits

64PalGov © 2011



Authentication

Session 5 Outline:



• SSL/TLS

• IPSEC

• Biometric authentication

65PalGov © 2011

• 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 Technology &

People, Vol. 7, No. 4, pp. 6-37, 1994.

[2] E. Newham, The Biometric Report. http://www.sjb.com/: SJB Services, New York, 1995

Biometric AuthenticationExtracted from [1],[2]

66PalGov © 2011

• H: High, M:Medium, L:Low

• Tabulated values from INTRODUCTION TO BIOMETRICS,Anil Jain,Michigan State University

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

GeometryM 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

67PalGov © 2011

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

Biometric Authentication continue www.biometrics.gov

68PalGov © 2011

Biometric System Operation

User

Sensor

Biometrics

extraction

Processing

Features extraction

Template is sore in

Database

Enrollment Process

Identity

User

Sensor

Biometrics

extraction

Processing

Features extraction

Search through

Database

Identification

User

Sensor

Biometrics

extraction

Processing

Features extraction

Database

Verification

Identity

Matching

Identified /

Unidentified

Accept /

Reject

69PalGov © 2011

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

Biometric System Operation continue

70PalGov © 2011

Biometric System Operation continueLecture slides by Lawrie Brown

Choosing this is very

critical in biometrics

71PalGov © 2011

1. Spoofing: a fake biometric is presented at the

sensor.

2. Sensor Bypass: illegally intercepted data is

resubmitted (replay)

3. Overriding feature extraction: feature detector is

replaced by a Trojan horse program to produces

feature sets chosen by the attacker.

4. Tampering with feature representation: legitimate

features are replaced with a synthetic feature set

5. Corrupting the matcher: matcher is replaced by a

Trojan horse program to produce scores chosen

by the attacker

6. Unauthorized access to stored templates

7. Corruption of template fetching

8. Decision override

Attacks on Biometric Systems

User

Sensor

Biometrics

extraction

Processing

Features extraction

Database

Verification

Identity

Matching

Accept /

Reject

1

2

3

4

5

6

7

8

72PalGov © 2011

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

Attacks countermeasures for Biometric

Systems

73PalGov © 2011

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

74PalGov © 2011

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.

Education

E gov security_tut_session_5