Internet Security CS587x Lecture Department of Computer Science Iowa State University

Internet SecurityCS587x Lecture

Department of Computer ScienceIowa State University

Internet Security IssuesA TCP/IP packet could go through many intermediate computers and separate networksPossible ways for communication interference

Eavesdropping Information remains intact, but its privacy is compromised.

For example, someone could learn your credit card number, etc.

Tampering Information in transit is changed or replaced and then sent

on to the recipient. For example, someone could alter an order of goods

Impersonation Information passes to a person who poses as the intended

recipient. For example, a person can pretend to have the email address [email protected] or a computer can identify itself as www.mozilla.com while it is not

Public-Key CryptographyThe goals of developing this standard Encryption and decryption

Allow two communication parties to disguise information they send to each other

Tamper detection Allows the recipient of information to verify that it

has not been modified in transit Authentication

Allows the recipient of information to determine its origin, i.e., confirm the sender’s identity

Nonrepudiation Prevents the sender of information from claiming

at a later date that the information was never sent

Encryption and DecryptionEncryption is a process of transforming information so it is intelligible to anyone but the intended recipientDecryption is a process of transforming encrypted information so it is intelligible againA cryptography algorithm (also called cipher) is a mathematical function used for encryption or decryption.

In most cases, two related functions are employed, one for encryption and the other for decryption

Cryptography algorithms are widely knownThe ability to keep encrypted information secret is based not on the cryptography, but on a number called key

Key is used with the algorithm to produce an encrypted result or to decrypt previously encrypted information

Symmetric-Key EncryptionWith symmetric-key encryption, the encryption key can be calculated from the decryption key and vice versaWith most symmetric-key encryption, the same key is used for both encryption and decryption

Symmetric-Key EncryptionAdvantages

Highly efficient implementation fast encryption and decryption

Provides some degree of authentication information encrypted with one symmetric key cannot

be decrypted with any other symmetric key.Disadvantages

Effective only if the key is kept secret by the two parties involved

If anyone else discovers the key, it affects both confidentiality and authentication

The person not only can decrypt messages sent with that key, but can encrypt new messages and send them as if they came from one of the two parties who were originally using the key

Public-Key Encryption Public-key encryption (also called asymmetric encryption) involves a pair of keys – public key and private key

Public key is published and could be well-known Private key is associated with an entity that needs to

authenticate its identity electronically or to sign or encrypt dataData encrypted with a public key can be decrypted only with some corresponding private key

To send data to someone, you encrypt the data with his public key, and the person receiving the encrypted data decrypts it with the corresponding private key

Data encrypted with private key can be decrypted only with corresponding public key (more details later)

Public-Key EncryptionAdvantage

Allow to freely distribute public key to the sender Private key can be kept in secretDisadvantage

Compared with symmetric-key encryption, public-key encryption requires more computation and is therefore not always appropriate for large amounts of data

The way to leverage the advantage and minimize the disadvantage

Use public-key encryption to send a symmetric key, which can be then be used to encrypt additional data. This is the approach used by the SSL protocol

Temper DetectionEncryption and decryption solves only the problem of eavesdroppingThe problem of tampering and impersonation remains

Tamper detection is done by using public-key encryption for digital signature

Impersonation can be addressed by certification and authentication

Digital SignatureTamer detection replies on a mathematical function called a one-way hash (also called a message digest)A one-way hash is a number of fixed length with the following characteristics

Ideally, the value of the hash is unique for the hashed data. Any change in the data, even deleting or altering a single character, results in different value

The content of the hashed data cannot, for all practical purposes, be deduced from the hash – which is why it is called “one-way”

Digital SignaturePublic-key encryption allows you to use your private key for encryption and your public key for decryptionThis feature can be used to digitally signing any data

The signing software creates a one-way hash of the data, then uses your private key to encrypt the hash

The encrypted hash, along with other information, such as the hashing algorithm, is known as a digital signature

Digital Signature

The source sends data as follows One-way hash the original data is one-way hashed Encrypt it with your private key Send both the original data and digital signature to the recipientThe recipient validates the data integrity as follows

Decrypt the digital signature using the public key Use the same hash algorithm to one-way hash the received data The data has not been tempered if the two sets of data are the

same

A Certificate Identifies an Entity

What is certificate? A certificate is an electronic document used

to identify an individual, a server, a company, or some other entity Just like a driver license identifies a person

Who issues certificate? Certificate Authorities (CA)

can be either independent third party or organizations running their certificate-issuing server software

Before issuing a certificate, CA must go through certain verification procedures, depending on the CA’s policies

Certificate ContentEach certificate always binds a particular public key to the certified entity

Only the public key certified by the certificate will work with the corresponding private key possessed by the owner of the certificate

includes the digital signature of the issuing CA For tempering detection - you cannot change a certificate The signature allows the certificate to function as a “letter of

introduction” for users who know and trust the CA but don’t know the entity identified by the certificate

Of course, a certificate also includes the name of the entity it identifies, an expiration date, the name the of CA that issued the certificate

Sample Certificate Content

openssl x509 -noout -text -in thawte. cerCertificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: md5WithRSAEncryption Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting, OU=Certification Services Division, CN=Thawte Personal Basic CA/[email protected] Validity Not Before: Jan 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, OU=Certification Services Division, CN=Thawte Personal

Basic CA/[email protected] Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:bc:bc:93:53:6d:c0:50:4f:82:15:e6:48:94: a6:5a:be:6f:42:fa:0f:47:ee:77:75:72:dd:8d:49: 9b:96:57:a0:78:d4:ca:3f:51:b3:69:0b:91:76:17: 22:07:97:6a:c4:51:93:4b:e0:8d:ef:37:95:a1:0c: 4d:da:34:90:1d:17:89:97:e0:35:38:57:4a:c0:f4: 08:70:e9:3c:44:7b:50:7e:61:9a:90:e3:23:d3:88: 11:46:27:f5:0b:07:0e:bb:dd:d1:7f:20:0a:88:b9: 56:0b:2e:1c:80:da:f1:e3:9e:29:ef:14:bd:0a:44: fb:1b:5b:18:d1:bf:23:93:21 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE Signature Algorithm: md5WithRSAEncryption 2d:e2:99:6b:b0:3d:7a:89:d7:59:a2:94:01:1f:2b:dd:12:4b: 53:c2:ad:7f:aa:a7:00:5c:91:40:57:25:4a:38:aa:84:70:b9: d9:80:0f:a5:7b:5c:fb:73:c6:bd:d7:8a:61:5c:03:e3:2d:27: a8:17:e0:84:85:42:dc:5e:9b:c6:b7:b2:6d:bb:74:af:e4:3f: cb:a7:b7:b0:e0:5d:be:78:83:25:94:d2:db:81:0f:79:07:6d: 4f:f4:39:15:5a:52:01:7b:de:32:d6:4d:38:f6:12:5c:06:50: df:05:5b:bd:14:4b:a1:df:29:ba:3b:41:8d:f7:63:56:a1:df: 22:b1

Authentication Confirms an Identity

Password-based authentication1. A client submits user name and password 2. Server checks database to see if name and password

matchCertificate-based authentication

1. A client digitally signs some piece of data, which are randomly generated based on the input from server and client Both client and server must know exactly the data to be

signed2. The client sends both the certificate and the signed

data to the server3. The server uses the public key in the certificate to

decode the signed data The signed data is an “evidence” used to verify if the

client owns the private key corresponding to the public key stored in its certificate

Certificate-based authentication

Types of CertificatesClient/server certificates Used to authenticate client/server via SSLS/MIMI certificates Used for signed and encrypted emailObject certificates Used to identify signers of Java code or

other signed filesCA certificates Used to identify Certificate Authorities

that can be trusted

Establishing trust through CA Certificates

Any client/server software that supports certificates maintains a collection of trusted CA certificatesIt is possible to delegate certificate-issuing responsibility to subordinate CAs, thus, creating CA hierarchies The root CA’s certificate is a self-signed certificates,

i.e., it is digitally signed by the same entity The CAs that are directly subordinate to the root CA

have CA certificate signed by the root CA CAs under the subordinate CAs in the hierarchy

have their CA signed the higher-level subordinate CAs

CA Hierarchies

Note: each certificate is signed with the private key of its issuer so that its authenticity can be verified through its public key

Certificate Verification

Certificate StandardsX.509 Standard Created to provide credentials for X.500

directory objects V1 published as part of X.500 directory

recommendations V3 (1996) added much flexibility

added provisions for “extension” fields (“V3 extensions”)

V3 use pretty much universal for Internet applications supports mail, c/s, IPsec alternatives limited to special purposes, e.g PGP

certificates

Design Goals of Secure Sockets Layer

Negotiates and employs essential functions for secure transactions

Mutual Authentication Establish trust with intended recipients Signed Digital Certificates

Server Authenticates to Client Client Authenticates to Server (optional)

Data Encryption Privacy and confidentiality Support different algorithms for different application needs

Data Integrity Insure no one tampers with data transmissions intentionally

or not Freshness of transactions to avoid replays

As simple and transparent as possible, seamlessly integrated into existing protocols including TCP/IP

Secure Sockets Layer (SSL)

Platform and Application Independent Operates between application and

transport layers

TCP/IPSSLSSL

HTTP

Web Applications

NNTP FTP Telnet NewAppsEtc.

TCP over IP

IP Header

Src Dst

IP Data

TCP Header

Type:TCP

TCP Data

SrcPort

DstPort

SeqNum Application Data

SSL over TCP over IP

IP Header

Src Dst

IP Data

Type:TCP Encrypted

ApplicationData

TLS TLS Payload

TCP Header

SrcPort

DstPort

SeqNum

TCP Data

SSL 3.0 LayersRecord Layer

Fragmentation Compression Message Authentication (MAC) Encryption

Alert Layer close errors message sequence errors bad MACs certificate errors

Handshake Layer* All messages are MAC’d Message order is absolute Negotiation messages are created here and handed to

record layer

SSL HandshakeSSL protocol uses a combination of public-key and symmetric key encryption Symmetric key encryption is much faster

than public-key encryption Public-key encryption provides better

authentication techniquesEach SSL session always begin with an exchange of messages called SSL handshake Allows the server to authenticate itself to the

client using public-key techniques Allows the client and the server to cooperate

in the creation of symmetric keys used for rapid encryption, decryption, and tamper detection during the session that follows

Handshake Protocol1. The client sends the server

the client’s SSL version number, cipher settings, randomly generated data, etc.

2. The server sends the clientThe server’s SSL version number, cipher settings, randomly generated data, etc. The server’s own certificateRequest for the client’s certificate if the client is requesting a server resource that requires client authentication

3. The client and the server selects a common cipher Allows use of multiple ciphers because:

– Some countries disallow the use of strong ciphers– Strong ciphers may require too much computational

overhead– Some communications must be secured with a strong

cipher SSL uses strongest commonly-allowed cipher suite

Handshake Protocol Summary

4. The client uses some of the information sent by the server to authenticate the server

If the authentication fails, terminate the connection5. The client creates the premaster secret for the session,

using the data generated during the handshake so farThe secret is sent to the server after encrypted with the server’s public key (obtained from the server’s certificate)Only the corresponding private key can correctly decrypts the secret, so the client has some assurance that it is talking to the authentic server

6. If the server requests client authentication (optional), the client also signs another piece of data and sends it with the client’s certificate

The data must be unique to this handshake and known by both the client and the server (why?)Terminate the connection if authentication fails

SSL Handshake Protocol7. Both the server and client follow the same

steps to generate the master secret from the same premaster secret

If the server does not have the right private key, it cannot generate the right master secret

8. Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to

encrypt and decrypt information exchanged during the SSL session verify data integrity, i.e., detect any changes in the data between the time it was sent and the time it was received

9. Finishing handshakeThe client and the server send each other a message informing that future messages from will be encrypted with the session key

Session Key GenerationPremaster

Secret

MasterSecret

SessionKey

• Both server and client need to generate the session key• The session key is not sent via network

A Simplified Way?

1. Server sends its public key to the client2. Client generates the session key, encrypts it

with the public key and then sends the encrypted session key to the server

3. The server decrypts the message and gets the key

4. Server and client now use the same session key to encrypt and decrypt their communication

client serversend its public key to the client

Use the public key to encrypt the session key

Man-In-The-Middle Attack

• A simple scenario: 1. When M receives the public key from S, M replaces

the public key with its own public key2. M sends its own public key to C3. C generates the session key, encrypts it with the

public key and then sends the encrypted session key to M

4. M decrypts the message with its own private key and gets the session key

5. M encrypts the session key with the public key from S and forwards the result to S

6. M can now eavesdrop all communication between S and C

• How about verifying the digital signature of C?

C SMkeykey’

session key encrypted with key’

session key encrypted with key

Checking Server Certificate

Checking Client Certificate

Java SSLJava 1.4 includes Java Secure Socket Extention (JSSE)

JSSE can be downloaded and installed into previous versions of Java

Obtain SSLSocket or SSLServerSocket objects via javax.net.ssl's SSLServerSocketFactory and SSLSocketFactory classes

JSSE API: Client Socket Factory Methods

javax.net.ssl.SSLSocketFactory methods: static SocketFactory getDefault() Socket createSocket(String host, int port) Socket createSocket(String host, int port,

InetAddress localHost, int localPort) Socket createSocket(InetAddress host, int port) Socket createSocket(InetAddress host, int port,

InetAddress localHost, int localPort) Socket createSocket(Socket socket, String host, int

port, boolean autoClose) String[] getDefaultCipherSuite() String[] getSupportedCipherSuites()

JSSE API: Client Socket Methods

javax.net.ssl.SSLSocket methods (extends Socket):

Supported SSL cipher suites: String[] getEnabledCipherSuites() String[] getSupportedCipherSuites() void setEnabledCipherSuites(String[] suites)

SSL session creation enabled? boolean getEnableSessionCreation() void setEnableSessionCreation(boolean flag)

SSL client authentication required? boolean getNeedClientAuth() void setNeedClientAuth(boolean need)

JSSE API: Client Socket Methods (2)

Change from SSL client to SSL server mode: boolean getUseClientMode() void setUseClientMode(boolean mode)

Initiate the SSL handshake protocol: void startHandshake()

Add/remove SSL handshake listener (notified when SSL handshake operations complete on the socket)

void addHandshakeCompletedListener (HandshareCompletedListener listener)

void removeHandshakeCompletedListener (HandshareCompletedListener listener)

JSSE API: Server Socket Factory Methods

javax.net.ssl.SSLServerSocketFactory methods:

static ServerSocketFactory getDefault() ServerSocket createServerSocket(int port) ServerSocket createServerSocket(int port, int

LQsize) ServerSocket createServerSocket(int port, int

LQsize, InetAddress localAddress) String[] getDefaultCipherSuites() String[] getSupportedCipherSuites()

JSSE API: Server Socket Methods

javax.net.ssl.SSLServerSocket methods: Supported SSL cipher suites:

String[] getEnabledCipherSuites() String[] getSupportedCipherSuites() void setEnabledCipherSuites(String[] suites)

SSL session creation enabled? boolean getEnableSessionCreation() void setEnableSessionCreation(boolean flag)

SSL client authentication required on accepted sockets? boolean getNeedClientAuth() void setNeedClientAuth(boolean need)

Switch accepted sockets from SSL client mode to SSL server mode

boolean getUseClientMode() void setUseClientMode(boolean mode)

Example Serverimport java.io.*;import javax.net.ssl.*;public class EchoServer { public static void main(String [] arstring) { try { SSLServerSocketFactory sslserversocketfactory = (SSLServerSocketFactory)SSLServerSocketFactory.getDefault(); SSLServerSocket sslserversocket = (SSLServerSocket)sslserversocketfactory.createServerSocket(9999); SSLSocket sslsocket = (SSLSocket)sslserversocket.accept();

InputStream inputstream = sslsocket.getInputStream(); InputStreamReader inputstreamreader = new InputStreamReader(inputstream); BufferedReader bufferedreader = new BufferedReader(inputstreamreader);

String string = null; while ((string = bufferedreader.readLine()) != null) { System.out.println(string); System.out.flush(); } } catch (Exception exception) { exception.printStackTrace(); } } }

Example Clientimport java.io.*;import javax.net.ssl.*;public class EchoClient { public static void main(String [] arstring) { try { SSLSocketFactory sslsocketfactory = (SSLSocketFactory)SSLSocketFactory.getDefault(); SSLSocket sslsocket = (SSLSocket)sslsocketfactory.createSocket("localhost", 9999);

InputStream inputstream = System.in; InputStreamReader inputstreamreader = new InputStreamReader(inputstream); BufferedReader bufferedreader = new BufferedReader(inputstreamreader);

OutputStream outputstream = sslsocket.getOutputStream(); OutputStreamWriter outputstreamwriter = new OutputStreamWriter(outputstream); BufferedWriter bufferedwriter = new BufferedWriter(outputstreamwriter);

String string = null; while ((string = bufferedreader.readLine()) != null) { bufferedwriter.write(string + '\n'); bufferedwriter.flush(); } } catch (Exception exception) { exception.printStackTrace(); } }}

Running the Samplesjava -Djavax.net.ssl.keyStore=keystore -Djavax.net.ssl.keyStorePassword=keystorePassword EchoServerjava -Djavax.net.ssl.trustStore=truststore -Djavax.net.ssl.trustStorePassword=truststorePassword EchoClient

Java Certificate Classesjava.security.cert

Certificate (abstract class) CRL (abstract class) CertificateFactory

To obtain instances of Certificates and CRLs X509Certificate extends Certificate X509CRL extends CRL

CertificateFactory Classpublic static CertificateFactory getInstance(String stringType)

Type is, e.g., “X.509”public static CertificateFactory getInstance(String stringType, String stringProvider)public final Certificate generateCertificate(InputStream inputstream)public final Collection generateCertificates(InputStream inputstream)public final CRL generateCRL(InputStream inputstream)public final Collection generateCRLs(InputStream inputstream)

Certificate Interfacepublic abstract PublicKey getPublicKey()public abstract byte [] getEncoded()public abstract void verify(PublicKey publickey)public abstract void verify(PublicKey publickey, String stringProvider)

X.509 Certificate Interfacepublic abstract byte [] getEncoded()

Returns certificate encoded in DER formatpublic abstract int getVersion()public abstract Principal getSubjectDN()public abstract Principal getIssuerDN()public abstract Date getNotBefore()public abstract Date getNotAfter()public abstract BigInteger getSerialNumber()public abstract String getSigAlgName()public abstract String getSigAlgOID()public abstract int getBasicConstraints()public abstract boolean [] getKeyUsage()public Set getCriticalExtensionOIDs()public Set getNonCriticalExtensionOIDs()

SummaryIntroduction to cryptography

Symmetric key and public key encryption/decryption

Digital signature CertificateSecure Sockets Layer

SSL handshakeJava Secure Sockets Extensions

Socket factories SSLSockets and SSLServerSocketsSample client and server