CSC17 New Assignment:

		       Due Wednesday 5/6

	  OVOAP: Our Very Own Authentication Protocol

We've learned that authentication, or anti-spoofing, is a key
instrument of network security.  Packet filtering firewalls such as
provided by Linux and iptables can give us a certain level of
assurance, but there are ways to get around it.  For example, we may
try to refuse ssh service by blocking connections to port 22.  But one
can run the ssh server on some other port, or use DNAT to bounce from
one port to another.  One can also write a "proxy" rely program to
accept data on one socket and send it over another.  A properly
configured firewall is very useful, especially if it can identify the
physical origins of a packet.  But this is often not possible, as for
example, when wireless connections are present, or if our router
depends on a higher-up router which may or may not implement the
security measures we may wish to assume.  We may also wish to
authenticate a client (or server) based on more than just tcp/ip
information, such as the username of the client.  With a
packet-filtering firewall, we often cannot afford to make it too rigid
lest we put unnecessary restrictions on ourselves.  By lifting
authentication up to its own layer of abstraction (above tcp/ip), we
give ourselfs greater flexibility in implementing security measures.

For this assignment we will implement a simplified version of the
"Kerberos" system, and which is described in chapter 8 of your
textbook.  Our protocol (OVOAP) depends on two key ingredients.  The
first is the existence of a "trusted" third-party authentication
server - someone such as the official system administrator that you've
decided is trustworthy.  The second ingredient is an encryption scheme.
and we'll use a very easy-to-implment two step scheme involving a
"key" and a permutation.  The key is a 512 byte randomly generated sequence
assigned to your host (find in guest home directory).
To apply the key to a 512 byte buffer, we apply the bitwise xor operation.
The "perm" is a 2048 byte file that contains an array of 512 4-byte
integers.  the permutation allows us to permute the bytes of an array to
different locations.

Given:  (BSIZE should be 512)

     byte[] Ms = new byte[BSIZE];    // message to be encrypted
     byte[] Cy = new byte[BSIZE];    // ciphertext buffer (encrypted Ms)
     byte[] keyA = new byte[BSIZE];  // key for connecting client
     int[] permA = new int[BSIZE];      // permutation for A 

The following code shows how to load the key/perm from file and apply them:

    // load permutation and key files:
    DataInputStream fink = new DataInputStream(new FileInputStream("my.key"));
    j = fink.read(keyA,0,BSIZE);
    fink.close();
    DataInputStream finp = new DataInputStream(new FileInputStream("my.perm"));
    for(i=0;i<BSIZE;i++) permA[i]=finp.readInt();
    finp.close();

    // apply both perm and key (perm(key)) to message Ms, store in Cy:
    for(i=0;i<BSIZE;i++)
	Cy[permA[i]] = (byte)((byte)Ms[i]^(byte)keyA[i]);

    To decrypt the ciphertext Cy back to Ms, we basically reverse the
    assignment statement:

    for(i=0;i<BSIZE;i++) 
	Ms[i]=(byte)((byte)Cy[permA[i]]^(byte)keyA[i]);

You should be able to also figure out how to apply the key and perm
separately.  The typecasting to (byte) is needed because java's ^
operation only works on ints.  In C it's not necessary.

--------------------------------------------------------------------
I will use the following notation in describing the protocol:

permA(S) : means the permutation for agent A applied to the sequence S
keyA(S)  : means the key for A xor'ed with S

See notes one how to implement these operations below.

So permA(keyA(S)) means applying the encryption algorithm for agent A
to buffer S.  Note that since the permutation is used, all sequences
will be in chunks of 512 bytes.  (For this assignment you don't have
to worry about multiple chunks.)

The protocol works as follows:

Let's say that agent A wants to open a connection to agent B. Here, A and
B should be strings such as "deepdish" and "thincrust".

1.  A opens a tcp connection to the trusted authentication server (TAS) on 
port 20004. It identifies both itself and B, the server it wants to contact.
That is, it sends (A,B) to the server. This information is sent in a
128-byte fixed-size buffer.  The first 64 bytes contains a zero-terminated
string identifying A, and the next 64 bytes does likewise for B.  See the
end of this document for help on how to construct the array.

2.  The server generates a random 512-byte key, which we will call
KeyS or "session key".  It also generates another 512 byte random
sequence which we will call the Stamp or "session stamp".  It sends
back to A exactly 2048 bytes, which represents four distinct
pieces of information.  Please understand that TCP is a "byte stream"
protocol, so you can choose to use either a single read into one large
buffer, or four separate reads to smaller buffers; it doesn't matter.

  s1: 1st 512 bytes:  permA(keyA(keyS));  (keyS,stamp encrypted for A)
  s2: 2nd 512 bytes:  permA(keyA(Stamp)); 
  s3: 3rd 512 bytes:  permB(keyB(keyS));  (keyS,stamp encrypted for B)
  s4: 4th 512 bytes:  permB(keyB(Stamp));

The trusted server has everyone's key and permutation.  Now, if both
agents (A and B) are who they say they are, they should be able to
decode keyS and Stamp, and prove to eachother by showing that they have
done so ...

3.  A now contacts the server B on port 30003.  It then sends to B 3*512
    bytes of information:

  s1: 1st 512 bytes: permB(keyB(keyS)) 
  s2: 2nd 512 bytes: permB(keyB(Stamp))
  s3: 3rd 512 bytes: keyS(Stamp)

  Note that the first two segments (s1,s2) is just exactly what A
received from the authentication server - A can't decrypt it because
it doesn't have B's key, so it's just passing the bytes onward.  The
3rd piece of information (s3) is proving to B that it is indeed A,
since B can then decode the Stamp and compare it with what it get from
s2.

4.  B decrypts KeyS and Stamp using its own key and perm. It also decrypts 
    s3 (keyS(Stamp)), and compare the decrypted pattern with the Stamp.
    If there's a mismatch, then A cannot be trusted.

    If A is indeed authentic, then B sends A one more 512-byte replay, which
    is the Stamp transmitted in the clear (proving to A that it too has the
    right key).  B now should expect a text message from A (in one 512-byte 
    chunk, unencrypted).

    If A is a fraud, then B sends in a 512-byte buffer a message such as
    "Your identity cannot be verified, I won't let you connect! Go 
     spoof someone else ..."

5.  A, on receiving this final 512 bytes, compares it with the Stamp 
    that it decrypted using its own key (and perm).  If there's a
    mismatch, then B couldn't decrypt Stamp correctly, so B cannot be
    trusted.

    A now sends one final text message to B, in the clear, again
    encoded in a 512 byte buffer.  The message should indicate to B
    if A believes that it's authentic.  For example, it can be:
         
     "Your identity has been verified. I'm OK you're OK..."
  
     or
   
     "You nasty hacker! You can't fool me!"

------------------------------------------------

The third-party authentication server is running on 10.1.0.3, port
20004.  You have to implement a client and a server program (A and B)
that conform to this protocol.  That is, it MUST work with other
people's clients and servers.  Word has it that there's one particularly
nasty client who likes to spoof you.

------------------------------------------------

Help in coding:

For packing strings into byte[] arrays, Java does have some built-in
functions (like getBytes), however, this protocol requires the
building of fixed-length packets.  In order to cram 2 strings into a
128-byte array in a fixed "packet format", we need to transmit the
strings as "zero-terminated" arrays of chars.  I found that the
built-in Java routines do not suffice for this purpose.  I've written
a set of routines to help you do this.  Download the file
"myutils.java" from the homepage and make sure it's in the directory
where you want to use it (no need need to "import").  Compile it
separately: javac myutils.java

Look at the file and learn how to use the following functions

StringToBuf  (write string to buffer)
BufToString  (decode buffer into string)
bufeq	     (tests if two buffers hold identical info)

To call them you can just say  myutils.StringToBuf(...), as long as
myutils.java is in the same directory, java will find it.

For C, these functions are not needed since strings are already just
arrays that are zero-terminated.  You can also use sprintf to construct
fixed-size arrays that contain strings, as in:

char buf[128];
sprintf(buf,"%s","thincrust");
sprintf(buf+64,"%s","deepdish");

------------------------

Also, look at the "other hints" link and use the readFully function during
communications.