20-CS-5153 Network Security Spring 2017
Semester Project/Contest

Secret Key, Public Key, Hash Algorithms, IPSec, Kerberos, Authentication, more

 
Stealing, Protecting, Authenticating

Due: Vicinity of the Spring Break

Objective:
    Groups of two to four students are to design and build Java (or C, C++, Perl, Prolog, Python, Haskell, etc.) (project) systems that will compete in a four day contest in the vicinity of but but during spring break. A group's project systems will attempt to accumulate points for the group via secure communications between two or more group project systems and between any group project system and a monitor. The monitor is a system that is maintained by the instructor and some interested senior students: it keeps track of and awards points and is the official scorekeeper. Each group will have three accounts. The group achieving the maximum number of points over all three accounts will be declared the winner. An up-to-date ranking of inviduals is available during the contest (see below).

The communication protocol is specified here. Each project system must be designed to comply with the protocol and should contain features intended to defend itself from attack by another group's project systems. Rules for accumulating points are stated below. Project systems should be based on work completed to solve Homeworks 2-4.

The protocol and monitor handling of messages is intended to show how many of the concepts that were learned during the quarter can be used in a practical setting. Such concepts include: secret key cryptography, public key cryptography, authentication, integrity protection, zero-knowledge proofs, RSA, Karn Symmetric Cryptosystem, Diffie-Hellman key exchange, login protocols, certificates.

The contest begins at 12:01AM, Thursday morning, 31 March, and ends 11:59PM, Saturday evening, 2 April.

Practice: connect to the monitor on port 8180 of helios.ececs.uc.edu for practice.
Practice rankings URL is http://gauss.ececs.uc.edu/standings8180.html

Contest: connect to the monitor on port 8150 of gauss.ececs.uc.edu for the contest.
Contest rankings URL is http://gauss.ececs.uc.edu/standings8150.html

Practice contest log file available at gauss.ececs.uc.edu:/var/www/html/practice.log.8180

Final contest log file available at http://gauss.ececs.uc.edu/final.log.8150
and
/home/httpd/html/final.log.8150 on helios.ececs.uc.edu

 
Connecting to the Contest Monitor on Gauss:
The problem is that port 8180 and port 8150 are not open outside of the UC network perimeter. There are several possibilities, two of which are given below.
  1. Run your active clients and passive servers from some computer inside the UC network perimeter, for example from helios.ececs.uc.edu.
  2. create two scripts, first one is called gauss-start and contains this:
      #!/bin/bash
      ssh helios.ececs.uc.edu -N -f -C -L 8150:gauss.ececs.uc.edu:8150 helios.ececs.uc.edu
      ssh helios.ececs.uc.edu -N -f -C -R 20000:localhost:20000
      sleep 2
      java -jar project.jar helios.ececs.uc.edu 8150 your-account-name
    
    where 20000 is a local port that can be replaced by whatever high number you want, your-account-name is the name of the contest account you are trying to log into, 8150 is the port the monitor is listening to on gauss, and all the java class files (if you are using java) are archived in a jar file named project.jar. It is assumed you have a Linux account on helios.eccecs.uc.edu. If not, use ucfilespace in the same way. In order to run the above you have to do the following:
      chmod a+x gauss-start
    
    Run the above like this:
      ./gauss-start
    
    You can do something similar in Windows. The second script is used to stop the ssh processes that the first script launches. Call it gauss-stop. The contents of this script are as follows:
      #!/bin/bash
      PIDS=`pidof ssh`
      for arg in $PIDS
      do
         kill -9 $arg
      done
    
    do
      chmod a+x gauss-stop
    
    to make it executable. Run it like this:
      ./gauss-stop
    
    You really want to kill those ssh processes when you are done. If you are unacquainted with jar files and want to archive the class files do the following, assuming the main class is called Project.java:
      javac Project.java
      jar cfm project.jar manifest.txt *.class
      rm -f *.class
    
    where manifest.txt contains this:
      Permissions: all-permissions
      Main-Class: Project
    
 
What to turn in after the contest:
  1. The name of all people for whom the code applies - this should be your group members. It is sufficient to just name the group as I can map group names to individual names.
  2. All source code with at least the following sections commented:
    • authentication of the monitor
    • zero-knowledge authentication of transfers
    • checking validity of a certificate
    • encrypting with a symmetric key cryptosystem
    • creating a session key
  3. A description of the approach you used to maintain security - include all the required components. This should take about 2 pages.
  4. A description of the approach you used to attack accounts (to steal wealth).
  5. Any other documentation you deem worthy to note - for example, problems you ran into and how they were solved.
  6. Citation of any material other than lecture notes that was used to create your code.
 
How to submit the above:
Email all files in a zipped or tared package as an attachment to franco@gauss.ececs.uc.edu. The subject of the email should be NetSec Project. The body of the email should include the names of all people the submission covers, the name of the group(s) those people were in, and any other pertinent information such as "my labrador retriever ran away from home and I had to spend a week to find him." Each person should associate with a single submission.
 
Project:
The full technical details of the contest are in the Protocol document. What follows in this document is simply an overview of the contest.
 
General Description:
Each group maintains three, fixed accounts each of which, at any point of time, holds a particular number of points. At the start of the contest each account holds 0 points. The number of points an account holds may be increased or decreased in several different ways:
  1. By transferring points, with permission, between accounts. All incoming transfers receive a 1% additional bonus. That is, if 1000 points are transferred into an account of group A from an account of group B by an agent of group C, the group A account will get 1010 points, and 1000 points will be deducted from the group B account. In this example, groups A, B, and C do not have to be distinct.
  2. By keeping alive a passive server which is officially registered as being alive. The longer the server is alive, the more points it gets. However, the server risks attack while alive.
  3. By stealing points from an account of another group (perhaps by spoofing that account to the monitor). To assist in this endeavor, all account activity is available in
           http://gauss.ececs.uc.edu/final.log.8150
    
    and /home/httpd/html/final.log.8150 of helios.ececs.uc.edu. Inbound encrypted transactions are decrypted in the log file and Outbound transactions are reported as is.
An account will lose 1% of its current value every time the monitor finds there is no running passive server representing that account when the monitor checks for alive servers. This check occurs at most CHECK_FOR_LIVING_MAXIMUM_TIME and at least CHECK_FOR_LIVING_MINIMUM_TIME seconds after the previous check (see http://gauss.ececs.uc.edu/Courses/c6053/project/GameParameters.java for the these times). Account activity is supported by a Monitor (the official) and group systems, three per group. The systems will comply with this communication protocol.
 
Monitor:
The monitor is maintained by the instructor and some interested senior students. It has numerous important functions as follows:
  1. It keeps track of accounts that are alive (registered).
  2. It keeps track of the number of points each account holds. Its database of points distribution is official. It keeps track of legitimate and spoofed transfers and does not distinguish between the two.
  3. It approves all communications. One reason for this is to slow down transfer rates to prevent network overload. Another reason is to limit the number of messages that can be sent from an account, also to prevent network overload.
  4. An account assigned to one group may coherce the Monitor to divulge information about an account registered to another group (an attempt may also be made to get a dim-witted system to divulge such information, independent of the Monitor).
  5. It acts as an identity certification authority in issuing certificates that are used to authenticate transfer initiators. See the section on authentication below for details.
The monitor will always be listening on port 8150 of gauss.ececs.uc.edu. Transactions with the monitor will always involve a handshake followed by a single line including a command followed by a list of arguments. Details of the handshake and a list of commands can be found in the protocol document.
 
Group Systems:
There will be at most one group system running under one account. A system does not always have to be running. However, a system must be running for at least one half hour in each three hour period to receive its full share of points in that period. When running, a system will operate from a port on a .uc.edu address. Every time a system starts it must register with the Monitor. A system may start, stop, and change ports many times during the day. This might be advantageous when hiding from an aggressive system. Changes to this information are communicated by means of commands issued to the Monitor. A system may be started on a different machine and a different port each time it goes on-line. Note: the Monitor only allows transactions with the most recently registered port and address for a given user.

Although it is possible to use the Monitor without encryption, we strongly urge you to encrypt all communications using available encryption facilities: that is, Diffie-Hellman key exchange using parameters contained in the java object file DHKey which was created by PlantDHKey.java; and Karn Symmetric encryption based on the secret constructed from the Diffie-Hellman exchange.

 
Point Transfers:
Define the following roles for parties involved in a transfer:
  • initiator: the account from which a TRANSFER_REQUEST command is executed with the intention of transferring points between two parties
  • sender: the account from which the points will be taken
  • recipient: the account to which the points will be given
Parties may transfer points between accounts as often as possible given the restrictions on rates of issuing commands. Transfers initiated by a third party are possible between any two distinct accounts with the following restrictions and bonus result:
  1. The sender and recipient must be different - otherwise a COMMAND_ERROR is generated.
  2. The initiator and sender must be different - otherwise a COMMAND_ERROR is generated.
  3. The initiator must be authenticated (that is, the initiator is the "prover"). See the authentication section for details.
  4. The recipient must authenticate the initiator (that is, the recipient is the "verifier"). See the authentication section for details.
  5. The recipient gets a bonus of 1% on top of the transferred points.
 
Monitor and Account Public and Private Keys:
The Monitor has an RSA public key e,n. The modulus component of the Monitor's public key, n, is available directly from the Monitor (see below). The encryption component, e, is the public value 65537, or 0x10001.

Authentication of recipients is accomplished through the Feige-Fiat-Shamir protocol. Thus, each account may have a public key pair v,n and a private key s where v is such that v = s2 mod n. An account owner should find a random number s and square it mod n to get value v.

The Monitor keeps a database of public certificates for each account, the certificate is just the SHA-1 hash of the account's public key pair signed with the Monitor's RSA private key. So, to get the resulting hash, one would take the signed certificate x and compute x65537 mod n.

This key authority system will be integral in the TRANSFER authentication process.

 
Authentication:
The Feige-Fiat-Shamir Zero Knowledge Proof protocol is supported to authenticate transfers. A participant chooses and keeps a secret S and a number n. A public key V = S*S mod n is computed. A certificate of the public key pair V,n is made by the monitor using the MAKE_CERTIFICATE command (see the next section below). The monitor signs the certificate with its RSA key.

Details of the authentication protocol, including a running example, may be found in assignment 4.

 
Certificates:
The Monitor is used as an identity certification authority. Certificates held by the Monitor certify Fiat-Feige-Shamir public keys to enable authentication when transfering points between accounts. Certificates are RSA signed by the Monitor whose public RSA key can be found at numerous points in the assignment and project documentation and can even be requested through the GET_MONITOR_KEY command. Certificates may be created by the Monitor after logging in. There are three protocol commands for working with certificates.

The GET_MONITOR_KEY command may be used to retrieve the Monitor's public key modulus for signature verification purposes as follows:

REQUIRE: COMMAND
WAITING:
GET_MONITOR_KEY
RESULT: MONITOR_KEY n
REQUIRE: COMMAND
WAITING:

where n is the public modulus of the monitor's RSA key. The other portion, e is the exponent and is the number 65537, or 0x10001. The monitor also has a hidden private key, d. The monitor signs some value m using x = md mod n, where m < n. A system may subsequently decipher this value and check it using m = xe mod n. The value m must be sufficiently small to "fit" in n, and therefore typically represents the SHA-1 hash of a larger dataset.

The monitor also provides a method for anyone to get the certificate for any system using the GET_CERTIFICATE command as follows:

REQUIRE: COMMAND
WAITING:
GET_CERTIFICATE PARTICIPANT_SYSTEM_HANDLE
RESULT: CERTIFICATE PARTICIPANT_SYSTEM_HANDLE x

where x is the requested participant's certificate signed by the Monitor. The Monitor has a certificate which may be obtained by issuing:

GET_CERTIFICATE MONITOR

A system may certify itself with one key at any time to the Monitor, this is done by completing the normal authentication steps and then providing the Monitor with its public key information v and n using the MAKE_CERTIFICATE command as follows:

REQUIRE: COMMAND
WAITING:
MAKE_CERTIFICATE v n
RESULT: CERTIFICATE REQUESTOR_HANDLE x
REQUIRE: COMMAND
WAITING:

The certificate c is the SHA-1 hash of the concatenation of v, then n (md.update(v); md.update(n)) and x = cd mod n, or the hash signed with the Monitor's RSA private key. The monitor saves x. This value is returned by the Monitor after the GET_CERTIFICATE command is executed. The participant decrypts this value using the Monitor's public key and compares with the hash of the values v and n of the participant whose public key it is trying to verify.