SDSU CS 580 Client-Server Programming
Fall Semester, 2002
Previous    Lecture Notes Index    Next    
© 2002, All Rights Reserved, SDSU & Roger Whitney
San Diego State University -- This page last updated 05-Dec-02

Contents of Doc 25, Security

NIH Security Web Site

Applied Cryptography Second Edition, Bruce Schneier, John Wiley & Sons, 1996

Red Team versus the Agents, Scientific American, December 2000, pp. 20, 24.

Doc 25, Security Slide # 2


Some common issues

Client (server) should be able to ascertain the origin of the message
Intruder should not be able to masquerade as someone else
Messages should not be modified in transit

Sender should not be able to falsely deny sending a message later
Intruders should not be able to learn sensitive data from a message

Users should be able to perform requests that they are authorized to perform

Doc 25, Security Slide # 3
Some Bad Ideas

Doc 25, Security Slide # 4
Security through Obscurity

Security relies on encryption/authentication methods are not obvious.

Some examples:

Doc 25, Security Slide # 5
Security in the Wrong Place

Always think about what you're trying to accomplish with a security system.


Client performs authentication locally

Doc 25, Security Slide # 6
Authentication without Checking

A server that has an authentication and authorization should precede actions that require authentication.


POP server without the different states

Doc 25, Security Slide # 7
Back doors

Programmers have the tendency to add debug code to their servers to make testing easier.

This debug code may circumvent any security features of the server.


Wizard command gave full root privileges to the user
The default distribution had this command enabled
The "Internet worm" used this to attack machines throughout the Internet.

Agent software based on Lisp
Agents could perform any Lisp string
Agents could request other agents to perform tasks
Intruders could masquerade as an agent

Doc 25, Security Slide # 8

General Security Issues

Points to keep in mind when dealing with security:

Some existing tools to look at:

Doc 25, Security Slide # 9
Network Authentication

Network packets can travel through many routers and computers.

The added risks

Some issues:

Doc 25, Security Slide # 10
Authentication methods: Basic

Username and password

Protocols we have seen that use this:


POP clients check for new mail periodically

Each check requires sending name/password

HTTP requests are made every time a page is requested.

Username and password get embedding in html pages

The more frequent the authentication information is sent over a network, the higher the chance that it will be sniffed.

Doc 25, Security Slide # 11

One-Way Hash Functions

Let M be a message (sequence of bytes)

A one-way hash function f() such that:

Common One-way Hash Functions

MD5 - Message Digest 5
SHA - Secure Hash Algorithm

Doc 25, Security Slide # 12
One-Way Hash and Logins

Let f() be a one-way hash function

Client has password and userName

Client with IP XXX connects to server

Client sends userName and f(password + XXX)

Server knows the client's IP address XXX from the connection

Server computes f(password + XXX) to validate password

Sniffer can only see f(password + XXX)

f(password + XXX) only works from the machine with IP XXX

Doc 25, Security Slide # 13
Using MD5 & SHA in Java

public class SampleCode 
   public static void main(String args[]) 
      throws NoSuchAlgorithmException
      MessageDigest sha = MessageDigest.getInstance("SHA");
      sha.update("Hi mom".getBytes());
      byte[] shaHash = sha.digest();
      System.out.println(new String(shaHash));
      MessageDigest md5 = MessageDigest.getInstance("MD5");
      md5.update("Hi mom".getBytes());
      byte[] md5Hash = md5.digest();
      System.out.println(new String(md5Hash));

Doc 25, Security Slide # 14
Using MD5 & SHA in Smalltalk

Load the MD5 & SHA parcels

'Hi mom' asByteArray md5Value


'Hi mom' asByteArray shaValue


Doc 25, Security Slide # 15
Using security tokens, tickets, or cookies

Applications using stateless protocols (http) need to authenticate every request

Server gives a security token to a client

The token identifies the client to the server

The client only authenticates once and thereafter uses the cookie

The authentication may involve "expensive" encryption

Some requirements for security tokens:

Doc 25, Security Slide # 16
Practical security token issues

How can a server identify a client with a token?

Rely on a piece of information that is hard to change: IP address of the client

The server must correlate the token with the address when the client uses it.

How can this be done?

A random string which identifies the client
A one-way scrambled string with client information

Doc 25, Security Slide # 17


After a client has been authenticated, the traffic on a network can still be sniffed.

A solution is encryption of all traffic.

This can be done at any layer of the protocol stack

Two basic types of encryption:

One key both encrypts and decrypts

One key encrypts, another decrypts

Doc 25, Security Slide # 18
Public/Private Key Encryption

A public key is something that is well known, i.e. published.

A client can send authentication information by encrypting the info with the server's public key.

The server will then use its own private key to decrypt the information.


Common Algorithms

RSA (Rivist, Shamir, Adleman)
DSA (Digital Signature Algorithm)

Doc 25, Security Slide # 19

Public Key

Key contains n & e where

n = p*q, p & q are primes
e relatively prime to (p-1)*(q-1)

p & q must be kept secret

Private Key

d is e -1 mod ((p-1)*(q-1))

that is (d*e) mod ((p-1)*(q-1)) = 1


Let m be a message such that m < n

Let c be the encrypted message

c = m e mod n

If m >= n then break into block smaller than n and encrypt each block


m = c d mod n

Doc 25, Security Slide # 20

Example is from page 467-8 of Schneier
Alice’s Keys

p = 47.
q = 71.

Then n = p*q = 3337

e = 79.

Then d = 79 -1 mod 3220 = 1019

So Alice’s public key is

n = 3337
e = 79

Alice’s private key is

d = 1019

Doc 25, Security Slide # 21
Sending a Message to Alice

Let m = 41

To send the message to Alice we compute

c = m e mod n = 41 79 mod 3337 = 875

We send 875 to Alice

Alice computes

cd mode n = 857 1019 mod 3337 = 41

Doc 25, Security Slide # 22
Digital Signatures

The same encryption method can be used to authenticate a message:

A client encrypts information with its own private key.

The server will lookup the client's public key and decrypt the information.


The information can only be decrypted with the client's public key.

If the public key distribution center can be trusted, the information is guaranteed to come from the client.

A combination of the previous two methods allows for mutual authentication.

Doc 25, Security Slide # 23
Alice Signing a Document

Let the document be 67

Alice uses private key to compute

67d mode n = 3081.

To validate the signature anyone can compute

3081e mod n = 3081 79 mod 3337 = 67

Copyright ©, All rights reserved.
2002 SDSU & Roger Whitney, 5500 Campanile Drive, San Diego, CA 92182-7700 USA.
OpenContent license defines the copyright on this document.

Previous    visitors since 05-Dec-02    Next