Description
I want a c code and I just only want the code for SYH Client SYH Server Public Key Server
Unformatted Attachment Preview
COSC 439: Computing Network Principles
COSC 522: Communication Networks and Distributed Systems
Project #1: Psst! A Secure Mailbox Service using SYH* Two-Step Authentication
I. Objectives:
Security is an important aspect of network communication. All types of data are being sent through computer
networks, some more sensitive than others. For these programming projects, you will be using RSA public
key encryption (PKE) to provide security services while exchanging messages using UDP sockets.
II. Introduction:
Psst! a sound that someone makes when they want to attract another person’s attention secretly or quietly. It
implies that the speaker is sending secret or whispered information to another person.
For this project, you will be writing a client/server application to implement a secure mailbox service called
Psst! using UDP sockets. Secure communication will be implemented using a two-factor authentication
called SYH* and end-to-end encryption using RSA public key encryption (PKE).
The components to this programming project are:
A. SYH Client (SYHC):
•
Implements the client part of two-factor authentication with the SYH server (SYHS).
B. SYH Server (SYHS):
•
Communicates with the Mailbox Server (MBS) and Psst! clients (PCs) to implement two-factor
authentication.
C. Public Key Server (PKS):
• Manages users’ public-keys.
D. Psst! Client (PC):
•
Provides a user interface that implements secure communication with other Psst! users.
•
Performs Psst! message encryption and decryption using RSA PKE.
E. Mailbox Server (MBS):
•
Performs two-step user authentication and maintains the mailboxes of encrypted “Psst!”
messages between users.
III.
Procedure:
A. SYH Client (SYHC)
The SYHC process should perform the following activities:
1. Prompts the user to enter the user ID.
2. Registers user’s UserID and address (IP address and port number) with the SYHS using a threeway handshake.
a. Generates a registerSYH message including a random integer (randInt) and a digital signature
(DS).
o The digital signature will be formed from using the user’s private key to encrypt the current
randInt.
o = !!” ( )
b. Sends registerSYH message
registerSYH(UserID, IP
address, Port #, randInt, DS)
UserID
randInt
= !!” ( )
KPr
c. Receives confirmSYH message
d. Sends ackRegSYH message
3. Provides an option for the user to respond to PUSH notifications from the SYHS.
a. Receives pushSYH message
b. Responds with ackPushSYH message
B. SYH Server (SYHS)
The SYHS process performs the following activities. The server should maintain a table of registered
userIDs with the corresponding SYHC IP address and port number.
1. Processes registration requests from SYHCs
a. Receives registerSYH messages
•
Authenticates message by verifying attached digital signature (DS).
o Sends requestKey to the PKS
o The SYHS should retrieve the registering user’s public key using the user’s
userID.
o Receives responseKey
b. Authenticates the registration request
•
Uses the registering user’s public key
•
Authentication process:
randInt
registerSYH(UserID, IP
address, Port #, randInt, DS)
DS
= !!# ( )
KPu
c. Sends confirmSYH messages to SYHC
•
If the registration request has been verified, then the SYHS should respond with a
confirmSYH message to the registering client.
d. Receives ackRegSYH message from SYHC to complete the registration process.
2. Processes authentication requests from MBS
a. Receives authentication requests from the MBS
• Receive requestAuth messages
b. Sends PUSH notifications to the corresponding user’s SYHC
•
Sends pushSYH messages
•
Receives ackPushSYH messages
c. Sends responseAuth messages to MBS
•
Responds to MBS with the status of the SYHC response (from b. above).
C. Public Key Server (PKS)
The PKS process performs the following activities. The server should maintain a data structure to store all
public keys that have been registered.
1. Processs key registration requests
a. Receives registerKey messages from PCs
b. Stores the received “# for each registered user
2. Processes key requests
a. Receives requestKey messages from PCs or SYHS
b. Responds with the requested “# in the responseKey message
D. Psst! Client (PC)
For purposes of making this project manageable, we will limit Psst! messages (PMs) to a maximum of 32
characters. The PC process should perform the following activities:
1. Prompts the user to enter the user ID, and both the public and private keys at start up.
2. Registers user’s own public key KPu to the PKS.
a. Sends a registerKey message to the PKS.
•
A client should register a public key to the server once with the corresponding user’s ID
(userID).
b. Waits to receive an ackRegisterKey message to confirm registration was successful.
3. Performs authentication process with MBS.
a. Sends a login message to the MBS at the beginning of each session
•
Generates a random integer (randInt).
•
A login message should contain (userID, randInt, DS).
o ( , , )
•
The digital signature will be formed from using the user’s private key to encrypt the current
randInt.
o = !!” ( )
UserID
randInt
login(UserID, randInt, DS)
= !!” ( )
KPr
b. Receives ackLogin message
• The client must wait for an ackLogin message before allowing the user to send or retrieve PMs.
c. Displays descriptive error messages if any part of the authentication process fails.
4. Provides an option for the user to send PMs to other users via the MBS.
a. Retrieves the recipient user’s public key from the PKS.
•
Sends requestKey
o The client should be able to request for the recipient user’s public key to the server using
the recipient user’s userID.
•
Receives responseKey
o The client should use the received public key to generate the PM.
b. Sends PMs.
•
The client should be able to send messages to any known user. The messages should be
encrypted using the recipient user’s public key.
o = !!# ( )
•
Sends sendMessage to send PMs to the MBS.
•
Waits to receive ackMessage to confirm a message was received by the MBS.
5. Provides an option for the user to retrieve PMs from the MBS.
b. Sends retrieveMessages request
o The client should be able to request to retrieve all his/her PMs
c. Receives ackRetrieve message that contains count of PMs to be retrieved
d. Receives all PMs forwarded by the MBS
o The client should be able to receive all PMs with its userID designated as the recipient.
o Receives psstMessages based on count received in ackRetrieve message
e. Reads/Displays all decrypted PMs received.
o Each PM should be decrypted using the user’s own private key and displayed.
o = !!” ( )
6. Exit – Provides an option for the user to exit the program. Client program should not quit.
E. Mailbox Server (MBS)
The MBS process performs the following activities. The MBS should maintain a data structure to store all
received PMs.
1. Processes login requests from a PCs
a. Performs two-step user authentication
•
Authenticates login message by verifying attached digital signature (DS).
o Retrieves the user’s public key from the PKS.
o Sends requestKey
o The MBS should send a request for the user’s public key
o Receives responseKey
o The MBS should use the received public key to authenticate the login request
o Authentication process:
login(UserID, randInt, DS)
DS
randInt
= !!# ( )
KPu
b. Once the login message is authenticated, then continue with the two-step authentication
c. Verifies user’s SYHC with the SYHS
•
Sends requestAuth message to SYHS with the UserID
•
Receives responseAuth message
d. If any part of the authentication process fails, a corresponding error message should be sent.
Only users that pass the two-step authentication should be allowed to communicate with other
users.
e. Sends an ackLogin message to verify login status.
2. Maintains the mailboxes of PMs received from PCs.
a. Receivse sendMessage messages
b. The server should store PMs by recipient UserID and send an ackMessage to acknowledge
received message to the sending client.
3. Processes requests to retrieve messages
a. Receives retrieveMessages
b. The server should send all stored PMs for the requesting recipient user using only one
psstMessages message.
IV.
Details:
The following details the structure formats and corresponding field values when exchanging messages
between entities. You MUST use the given struct definitions in your program.
Each running process should display messages describing pertinent activities as they occur (i.e., display a
message describing what message has been sent or received whenever each happens). All messages received
and displayed should also be labeled with the source of the message. Also, all processes should behave
sensibly when dealing with exceptions.
A. Messages to SYHS:
You should use the following definition for messages to the SYHS:
typedef struct {
enum {registerSYH, ackRegSYH, ackPushSYH, requestAuth, responseKey} messageType;
/* same size as an unsigned int */
unsigned int userID;
/* user identifier */
unsigned int randInt;
/* randInt */
unsigned int publicKey;
/* requested public key */
unsigned long digitalSig;
/* encrypted randInt */
} messageToSYHS;
a. messageType = registerSYH:
o Message sent from SYHC
o The userID field should contain the user’s own identifier when registering.
o The publicKey field should contain 0.
o The randInt field should contain current time
o The digitalSig field should contain encrypted randInt
b. messageType = ackRegSYH:
o Message sent from SYHC
o The userID field should contain the user’s own identifier.
o The publicKey field should contain 0.
o The randInt field should contain 0
o The digitalSig field should contain 0
c. messageType = ackPushSYH:
o Message sent from SYHC
o The userID field should contain the user’s own identifier.
o The publicKey field should contain 0.
o The randInt field should contain 0
o The digitalSig field should contain 0
d. messageType = requestAuth:
o Message sent from MBS
o The userID field should contain the user identifier during login.
o The publicKey field should contain 0.
o The randInt field should contain 0
o The digitalSig field should contain 0
e. messageType = responseKey:
o Message sent from PKS
o The userID field should contain the user identifier of requested public key
o The publicKey field should contain the requested user’s public key.
o The randInt field should contain 0
o The digitalSig field should contain 0
B. Messages to SYHC:
You should use the following definition for message to a SYHC:
typedef struct {
enum {confirmSYH, pushSYH} messageType;
unsigned int userID;
} messageToSYHC;
/* same as unsigned int */
/* user identifier*/
a. messageType = confirmSYH
o Message sent from SYHS
o Response to SYHC’s messageType = registerSYH
o The userID field should contain the registering user’s identifier.
b. messageType = pushSYH
o Message sent from SYHS
o Response to MBS’s requestAuth message
o The userID field should contain the user identifier
C. Messages to PKS:
You should use the following definition for messages to the PKS:
typedef struct {
enum {registerKey, requestKey} messageType; /* same size as an unsigned int */
unsigned int userID;
/* user’s identifier or requested user identifier*/
unsigned int publicKey
/* user’s public key or 0 if messageType is requestKey */
} messageToPKS;
a. messageType = registerKey:
o Message sent from PC
o The userID field should contain the user’s own identifier when registering.
o The publicKey field should contain the user’s own public key.
b. messageType = requestKey:
o Message sent from PC or SYHS
o The userID field should contain the identifier of the user whose public key it is
requesting.
o The publicKey field should be 0.
D. Messages to MBS:
You should use the following definition for messages to the MBS:
typedef struct {
enum {login, sendMsg, retrieveMsg, responseAuth} messageType; /* same size as an
unsigned int */
unsigned int userID;
/* user identifier */
unsigned int recipientID;
/* message recipient identifier */
unsigned long randInt;
/* randInt */
unsigned long digitalSig;
* encrypted randInt */
unsigned long psstMsg[32];
/* encrypted message, if used */
} PC_to_MBS;
a. messageType= login:
o Message sent from PC
o The userID field should contain the user’s own identifier when registering.
o The recipientID field should be 0.
o The randInt field should contain the current time
o The digitalSig field should contain the encrypted randInt
o The psstMsg field should contain all 0s.
b. messageType= sendMesg:
o Message sent from PC
o The userID field should contain the user’s own identifier when registering.
o The recipientID field should contain the user’s own public key.
o The randInt field should contain 0
o The digitalSig field should contain 0
o The psstMsg field should contain the encrypted message
c. messageType= retrieveMesg:
o Message sent from PC
o The userID field should contain the user’s own identifier when registering.
o The recipient_id field should contain the user’s own public key.
o The randInt field should contain 0.
o The digitalSig field should contain 0.
o The psstMsg field should contain all 0s
d. messageType= responseAuth:
o Message sent from SYHS
o The userID field should contain the user identifier during login.
o The recipient_id field should contain the user’s own public key.
o The randInt field should contain 0.
o The digitalSig field should contain 0.
o The psstMsg field should contain all 0s
E. Messages to PC:
You should use the following definition for messages from the MBS to a PC:
typedef struct {
enum {ackLogin, ackMessage, ackRetrieve, ackRegisterKey, responseKey} messageType; /*
same size as an unsigned int */
unsigned int userID;
/* user identifier */
unsigned int count;
/* number of messages */
unsigned int publicKey
/* requested public key */
} messageToPC;
a. messageType = ackLogin:
o Message sent from MBS
o Response to PC’s messageType = login
o The userID field should contain the registering user’s identifier.
o The count field should contain a count of messages available for retrieval.
o The publicKey field should contain 0.
b. messageType = ackMessage:
o Message sent from MBS
o Response to PC’s messageType = sendMessage
o The userID field should contain the user’s identifier.
o The count field should contain a zero.
o The publicKey field should contain 0.
c. messageType = ackRetrieve:
o Message sent from MBS
o Response to PC’s messageType = retrieveMessages
o The userID field should contain the user’s identifier.
o The count field should contain the count of messages the client should expect to receive.
The publicKey field should contain 0.
d. messageType = ackRegisterKey:
o Message sent from PKS
o Response to client’s messageType = registerKey
o The userID field should contain the registering user’s identifier.
o The count field should contain a zero.
o The publicKey field should contain the user’s public key.
e. messageType = responseKey:
o Message sent from PKS
o Response to PC’s messageType = requestKey
o The userID field should contain the user identifier of requested public key
o The count field should contain a zero.
o The publicKey field should contain the requested user’s public key.
o
You should use the following definition for messages from the MBS to a PC when receiving
messages:
typedef struct {
unsigned int userID;
unsigned long psstMsg[32];
} pmToPC;
V.
/* sender identifier */
/* encrypted message */
For COSC 522 students only
The following additional functionalities should be implemented to earn graduate credit for this project.
Server:
• The server should immediately send a notification to the recipient of the message received,
whenever a new message arrives.
Client:
• The client should be able to receive and display notifications from the server regarding new
messages.
FLOW CHARTS
VI.
Submission Requirements:
1. You are expected to work individually for this activity. You are allowed to modify the given echo
client/server programs. (Review the course policy on Academic Dishonesty.)
2. All code MUST be written in GNU C or C++ only. Your programs will be run and tested on
emunix.emich.edu. Therefore, you SHOULD test your programs on emunix before submission.
3. Make sure you provide sufficient documentation in the form of comments, white space, readable
identifiers, and a README text file describing the system operation (i.e., how to compile and run each
program) and its components.
4. Store all source code and the README file in a folder called your_last_name_Project1. Use zip to
compress the entire folder and upload your file using the designated project submission link.
VII.
Grading Criteria and Due Dates
Programing Projects are twenty percent (20%) of your final grade. Since parts of this project will be used
in Project #2., the overlap in both projects will count towards six percent (6%) of your final grade. Another
seven percent (7%) will be based on the rest of this project. The other seven percent (7%) of your final
grade will be allocated for Project 2.
Part 1 consists of code that will be used in both Projects 1 and 2:
•
SYH Client
30%
•
SYH Server
30%
•
Public Key Server
40%
•
Due Date: 11:59 pm, March 3, 2024
Part 2 consists of code that implements the Mailbox Service:
VIII.
•
Psst! Client
50%
•
Mailbox Server
50%
•
Due Date: 11:59 pm, March 17, 2024
Academic Dishonesty Policy:
Each student is expected to submit individually prepared work. You are free to discuss programming
projects with your classmates. However, the submitted work should reflect the individual student’s efforts.
Cheating, falsification, and /or plagiarism will not be tolerated. Since you will be modifying existing code,
make sure you make proper notations for citing code you used. Any student who submits work, which has
been determined as not his/her own, will be given a grade of ZERO for the first offense. In addition, ALL
other students involved will also be given a grade of ZERO. Any subsequent instance of academic
dishonesty will result in a failing grade (“F”) for the course and referral to Student Judicial Services for
disciplinary action.
*short for S**** You Hackers!
Purchase answer to see full
attachment
