|20-CS-6053||Network Security||Spring 2017|
Stealing, Protecting, Authenticating
Due: Vicinity of the Spring Break
|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 Labs 1-3 plus certificate management (see the Authentication section below.
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, Monday morning, 20 March, and ends 11:59PM, Wednesday evening, 22 March.
Practice rankings URL is http://gauss.ececs.uc.edu/standings8180.html
Contest: connect to the monitor on port
for the contest.
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
|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.
|What to turn in after the contest:|
|How to submit the above:|
|Email all files in a zipped or tared package as an attachment to firstname.lastname@example.org. 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 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.|
|The full technical details of the contest are in the Protocol document. What follows in this document is simply an overview of the contest.|
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:
The monitor is maintained by the instructor and some interested senior
students. It has numerous important functions as follows:
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.
Define the following roles for parties involved in a transfer:
|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.
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 Lab assignment 3.
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
even be requested through the
The GET_MONITOR_KEY command may be used to retrieve the Monitor's public key modulus for signature verification purposes as follows:
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:
where x is the requested participant's certificate signed by the Monitor. The Monitor has a certificate which may be obtained by issuing:
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:
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.