5b.1

Data Confidentiality and Data Integrity

ITCS 4146/5146, UNC-Charlotte, B. Wilkinson, 2007 Jan 30, 2007

5b.2

Data Confidentiality and Data Integrity

• Data Confidentiality - information exchange needs to protected against eavesdroppers.

• Data Integrity - need to assure that message was not modified in transit (intentionally or by accident).

5b.3

Achieving Data Confidentiality and Data Integrity

• “Encrypt” data in a form that makes it unreadable except by the parties that are to read it, and

• Attach a binary pattern with the message computed from the message, which changes if the message has been altered.

5b.4

Digital Signatures

• A way of achieving authentication and data integrity.

• Uses a hash function to create a message digest, a “footprint” of the message, which is encrypted with sender’s private key to create a digital signature.

• Digital signature attached to message.

5b.5

Hash Function

• Applying hash function to data will create a small fixed sized block of data, called in this in text a message digest.

• Cannot obtain original data from the digest - hence one-way.

• Changes to the data will usually alter the message digest.

5b.6

Digital Signature

my message that must be kept secret

asthf12934

Hash function Sender’s

Private Key

DataMessage

Digest

Digital Signature

Attach digital signature to message (data)

5b.7

Checking digital signatureReceiver can do the following:

1. Create a message digest from message using same hash function.

2. Decrypt message digest with sender’s public key.

3. Compare two message digests - if same message should be from sender and not altered.

5b.8

Checking digital signature

This is my message

Public key

Private Key

Original data

Network Original data

Digital signature

Hash

Hash

If same, data ok

Sender

5b.9

• Digital signature alone not sufficient to ensure data not altered and is from the sender.

• Possible that public key is a fake. Still could get matching digital signatures.

5b.10

Certificates

• A digital document belonging to the “End-Entity” giving:

– Their name, their public key, and other information.

• Certificate comparable to a Driver’s license or passport.

5b.11

CertificateCertificate

This certificate belongs to: Barry Wilkinson

Public key of certificate owner:

Signature of Certificate Authority: MyCA

Other information also on certificate, see later.

5b.12

Certificate Authority (CA)

• A trusted third party certifies that the public key does in fact belong to the end-entity on the certificate.

• The certificate is signed by the CA using their private key (which can be verified using their public key)

• Certificate Authority comparable to a DMV for Driver’s licenses or passport agency (US Dept of State) for passports.

5b.13

Certificate Authority

• Certificate Authority has to first create it’s own certificate to identify itself (keeping its private key protected).

• End-Entities submit their details to CA for CA to issue a certificate back to End-Entity.

5b.14

Types of Certificates

• X.509 most widely used.

• Defined by International Telecommunications Union (ITU)

• Version 1 defined in 1988

• Version 2 , Version 3 (1996) adds fields, see next slide.

5b.15

X.509 Format (version 3)

Certificate version

Certificate serial number

Issuer signature algorithm ID

Issuer X-500 name

Validity period

Subject X-500 name

Subject public key information: Algorithm ID; Public key value

Issuer unique ID

Subject unique ID

Extensions

Issuer digital signature

5b.16

Subject’s identity

X 500 namespace

• Entry identified by a distinguished name (DN)

• Hierarchical

• Unambiguous

• Concatenation of attributes

• Tree creating a path to the entry

5b.17

X 500 namespace• Entries organized in a tree hierarchy,

which could reflect the organizational structure:– Organization: O=Grid– Organization: O=UNCW– Organizational unit: OU= Dept of Computer

Science– Common name: CN=Clayton Ferner

Example in grid course/O=Grid/OU=UNCW/OU=Dept of

Computer Science/CN=Clayton Ferner

5b.18

Need to specify polices and how to establish subject’s identity.

5b.19

Must to constructed for uniqueness – could be two Barry Wilkinson’s (There are.)

Look at your DN (proxy management portlet)

5b.20

5b.21

Accepting Certificates

If• you trust the Certificate Authority

and

• you are confident that the key that you have is really the public key of the Certificate Authority

then

• you can decrypt the sender’s certificate with confidence to obtain the public key of the sender.

5b.22

• Public Key and Secret Key Cryptography generally used together.

• Public key Cryptography with Certificates and a Certificate Authority (CA) used to establish a secure authenticated connection between parties.

• Then:

– Secret key passed between parties.– Secret key cryptography used to encrypt data,

which is much faster than public key cryptography.

5b.23

Use of Public Key Infrastructure(PKI)

• Several network protocols have embedded public key and/or secret key cryptographic algorithms.

• Most notable is SSL (Secure Socket Layer) Protocol), which can be added on top of protocols such as http (i.e. https), FTP (sftp) – described later.

5b.24

Others include:

• S/MIME (Secure Multipurpose Internet Mail Extensions) -- for secure email, developed by RSA Data Security Inc, see:

http://www.rsa.com/smime

• SET (Secure Electronic Transaction) -- for

secure e-commerce, developed jointly by Visa, Mastercard, IBM, and other companies, for secure credit card transactions over the Internet, see:

http://www.setco.org

5b.25

Certificate Authorities

• Commercial Certificate Authorities exist, such as:

– VeriSign Inc.– Entrust Technologies Inc.,

• Web browsers have built-in recognition such trusted CAs, allowing SSL and other secure connections.

5b.26From: “Deploying a Public Key Infrastructure,” IBM Redbook

General Public Key Infrastructure

5b.27

Certificate Repository

• Used to store:– Issued certificates– Revoked certificates (CRLs - Certificate

Revocation List)– Might be accessed through LDAP

(Lightweight Directory Access Protocol)

5b.28

Registration Authority

• Acts for CA for some management functions (see IBM Redbooks).

• Not strictly necessary as CA could do all functions.

5b.29

CA’s own certificateCA needs it own certificate identify itself• First it generates key pair.• It protect its private key. (This is vitally

important!)• It then creates a

certificate and signsit with its private key:

CA’s public key

Certificate

CA’s digital signature

CA’s X-500 name

5b.30

Requesting a certificate from a CA

• Usually, requesting client generates a public/private key pair and then submits an unsigned certificate with public key to the CA.

• The certificate returned signed by the CA contains the public key.

5b.31

Question

Why usually does the CA not generate the public/private key pair for the requester?

5b.32

Answer

Because it would require the private key to be sent to the requester.

If the requester generates the private key, it is more secure as it does not leave requester.

5b.33

Using a signed certificate to send a secure message

• One can attached it to your message.

• Alternatively, the message is sent without a certificate and the receiver has to retrieve the certificate from a public place.

Either way, the receiver checks the signature. It has to be a CA it can trust.

5b.34

CertificateLifetime

• Certificates have a limited lifetime for security purposes, i. e. certificates are issued with an expiration date.

• Have a renewal process but user will normally have same public/private key pair.

5b.35

Systems/protocols using security mechanisms

5b.36

SSL (Secure Socket Layer) Protocol

• Uses public/private keys.

• Introduced by Netscape and widely adopted.

• Supported by both Netscape and Microsoft Internet Explorer browser.

• TLS (Transport Layer Security) newer but similar.

5b.37

• Requires several message to be exchanged between client and server

• Described here in four phases.

5b.38

Phase I

• Client starts handshake and sends:–a random number, X.

– list of supported ciphers and compression algorithms

5b.39

Phase II

• Server selects cipher and compression algorithm, and notifies client.

• Then it sends:–another random number, Y.

–a server certificate, which includes public key

5b.40

Phase III

• Client sends:– a “premaster” secret encrypting it

with server public key

–possibly a client certificate

5b.41

Phase IV• Handshake finished. Message sent to

inform client.

• Server and client each generate a master secret by combining random numbers X and Y, and the premaster secret.

• Several secret keys are generated from the master secret, one to encrypt the data.

• Encrypted data then sent to client.

5b.42

Client Server

5b.43

SSLEnsures:

• Authentication (by verifying certificates)

• Confidentiality (by encrypting data with secret key)

• Integrity (by digesting data)

Non-repudiation not ensured.

5b.44

Globus Grid Security Infrastructure(GSI)

• Uses public key cryptography.• Secure communication for authentication

etc.• Task communication can be encrypted with

shared key if required.• Security across organizational boundaries• Proxies provide “single sign-on”.

Next set of slides (Grid computing Security).

5b.45

More InformationOn-line

• “Deploying a Public Key Infrastucture,” IBM Redbooks:

http://www.redbooks.ibm.com

• For SSL protocol:

http://developer.netscape.com/docs/manuals/security/sslin/index.html

• Digital signatures:

http://www.youdzone.com/signature.html

5b.46

Certificates and Authentication

http://docs.sun.com/source/816-615410/contents.htm

Section starting with Certificates and Authentication

5b.47

Books

• “Cryptography and Network Security 3rd edition,” by William Stalling.