e gov security_tut_session_5
Post on 19-Jan-2015
486 Views
Preview:
DESCRIPTION
TRANSCRIPT
1PalGov © 2011
أكاديمية الحكومة اإللكترونية الفلسطينية
The Palestinian eGovernment Academy
www.egovacademy.ps
Dr. Mohammad Jubran
University of Birzeit
mjubran@birzeit.edu
Tutorial 5: Information Security
Session 5
Certificates and Biometric Authentication
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 mjarrar@birzeit.edu
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
Tutorial 5: Information Security
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
Tutorial 5: Information Security
Session 5: Certificates and Biometric
Authentication
Session 5 Outline:
• Session 5 ILO’s.
• PKI, X.509, and PGP
• 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.
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
Lecture Notes of David Chadwick
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.
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
X.509 Digital certificates
displayed in Microsoft
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
Self signed public key certificates
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)
Signature Algorithm: md5WithRSAEncryption
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
26PalGov © 2011
Self signed public key certificates
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)
Signature Algorithm: md5WithRSAEncryption
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
Certificate from http://en.wikipedia.org/wiki/X.509
27PalGov © 2011
Self signed public key certificates
Is this X.509 certificate a self signed certificate? Version: 3 (0x2)
Serial Number: 1 (0x1)
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: 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/emailAddress=server-certs@thawte.com
Subject Public Key Info: Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
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
Certificate from http://en.wikipedia.org/wiki/X.509
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
X.509 Digital certificates
displayed in Microsoft
explorer for the educational
management system (ritaj) at
Birzeit University
34PalGov © 2011
Certification Path
X.509 Digital certificates
displayed in Microsoft
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
X.509 Digital certificates
displayed in Microsoft
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
Lecture Notes of David Chadwick
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
Tutorial 5: Information Security
Session 5: Certificates and Biometric
Authentication
Session 5 Outline:
• Session 5 ILO’s.
• PKI, X.509, and PGP
• 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.
How SSL works continue
51PalGov © 2011
How SSL works continue
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
Tutorial 5: Information Security
Session 5: Certificates and Biometric
Authentication
Session 5 Outline:
• Session 5 ILO’s.
• PKI, X.509, and PGP
• 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
Tutorial 5: Information Security
Session 5: Certificates and Biometric
Authentication
Session 5 Outline:
• Session 5 ILO’s.
• PKI, X.509, and PGP
• 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.
top related