Internet Security

CS587x Lecture Department of Computer Science Iowa State University

Internet Security Issues

   A TCP/IP packet could go through many intermediate computers and separate networks Possible 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 Cryptography

The 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 Decryption

Encryption is a process of transforming information so it is intelligible to anyone but the intended recipient Decryption is a process of transforming encrypted information so it is intelligible again A 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 known The 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 Encryption

With symmetric-key encryption, the encryption key can be calculated from the decryption key and vice versa With most symmetric-key encryption, the same key is used for both encryption and decryption

Symmetric-Key Encryption

  Advantages  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 data Data 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 Encryption

  Advantage Allow to freely distribute public key to the sender Private key can be kept in secret   Disadvantage 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 Detection

  Encryption and decryption solves only the problem of eavesdropping The 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 Signature

  Tamer 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 Signature

 

Public-key encryption allows you to use your private key for encryption and your public key for decryption This 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 recipient The 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 Content

Each 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. cer Certificate: 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

1.

2.

Password-based authentication A client submits user name and password Server checks database to see if name and password match 1.

Certificate-based authentication A client digitally signs some piece of data, which are randomly generated based on the input from server and client 2.

3.

 Both client and server must know exactly the data to be signed The client sends both the certificate and the signed data to the server 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 Certificates Client/server certificates

 Used to authenticate client/server via SSL

S/MIMI certificates

 Used for signed and encrypted email

Object certificates

 Used to identify signers of Java code or other signed files

CA 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 certificates It 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 Standards

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

Web Applications HTTP NNTP FTP Telnet Etc.

New Apps SSL TCP/IP

TCP over IP

IP Header TCP Header IP Data TCP Data Src Dst Type: TCP Src Port Dst Port Seq Num Application Data

SSL over TCP over IP

IP Header IP Data TCP Header Src Dst Type: TCP Src Port Dst Port Seq Num TLS TCP Data TLS Payload Encrypted Application Data

SSL 3.0 Layers

Record 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 Handshake

SSL 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 techniques Each 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 Protocol

1.

2.

3.

  The client sends the server the client’s SSL version number, cipher settings, randomly generated data, etc. The server sends the client The server’s SSL version number, cipher settings, randomly generated data, etc. The server’s own certificate Request for the client’s certificate if the client is requesting a server resource that requires client authentication 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.

5.

6.

The client uses some of the information sent by the server to authenticate the server If the authentication fails, terminate the connection The client creates the authentic server premaster secret for the session, using the data generated during the handshake so far The 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 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 Protocol

7.

8.

9.

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 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 Finishing handshake The client and the server send each other a message informing that future messages from will be encrypted with the session key

Session Key Generation

Premaster Secret Master Secret Session Key • Both server and client need to generate the session key • The session key is not sent via network

A Simplified Way?

client send its public key to the client Use the public key to encrypt the session key server 1. Server sends its public key to the client 2. 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

Man-In-The-Middle Attack

• • C key’ key M S session key encrypted with key’ session key encrypted with key A simple scenario: 1. When M receives the public key from S, M replaces the public key with its own public key 2. M sends its own public key to C 3. 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?

Checking Server Certificate

Checking Client Certificate

Java SSL

 Java 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()    SSL session creation enabled?

boolean getEnableSessionCreation()  String[] getSupportedCipherSuites() void setEnabledCipherSuites(String[] suites) 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 Server

import 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 Client

import 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 Samples

java -Djavax.net.ssl.keyStore=keystore Djavax.net.ssl.keyStorePassword=keystorePassword EchoServer java -Djavax.net.ssl.trustStore=truststore Djavax.net.ssl.trustStorePassword=truststorePassword EchoClient

Java Certificate Classes

    

java.security.cert

Certificate (abstract class) CRL (abstract class)  CertificateFactory To obtain instances of Certificates and CRLs X509Certificate extends Certificate X509CRL extends CRL

CertificateFactory Class

 public 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 Interface

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

X.509 Certificate Interface

 public abstract byte [] getEncoded() Returns certificate encoded in DER format public 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()

Summary

 Introduction to cryptography Symmetric key and public key encryption/decryption   Digital signature Certificate  Secure Sockets Layer SSL handshake  Java Secure Sockets Extensions Socket factories  SSLSockets and SSLServerSockets Sample client and server