Question: I need a a client/server application to implement a somewhat secure brokerage service using UDP sockets. Secure communication between a client and the broker will
I need a a client/server application to implement a somewhat secure brokerage service using UDP sockets. Secure communication between a client and the broker will be through a four-way handshake using RSA public key encryption (PKE). A third-party program will act as the public-key manager. All communication between client and broker will be secured using RSA PKE.
Description:
The three components to this application are:
Broker: performs the brokering of stocks based on client requests.
Client: sends stock buy/sell requests to the broker.
Public-key Manager: manages public-keys sent by principals (clients and brokers).
Key Manager. The key manager process performs the following activities. Receive register messages from principals The key manager should maintain a table of public keys that have been registered.
Receive key requests from any principal The key manager should respond with the corresponding public key of the requested principal.
Send key request responses The key manager should respond with the corresponding public key of the requested principal.
Client. The client process should perform the following activities:
Send a register message to the key manager A client should automatically send a register message with the chosen public key to the key manager at startup.
Request public key The client should be able a request_key message to the key manager at any time for the public key of any known principal.
Send a buy or sell stock request The client should be able to send the request to a well-known broker. The message should be encrypted using the brokers public key.
Receive confirm request The client should be able to receive confirm message from the broker after sending a buy/sell request. The message should be decrypted using the clients private key.
Send a verify response The client should be able to send the response to the broker after receiving a confirm request. The message should be encrypted using the clients private key.
Receive a done response The client should be able to receive the done response from the broker after sending a verify response. The message should be decrypted using the broker's public key.
Exit Provide an option for the client program to quit.
Broker. The broker process should perform the following activities.
Send a register message to the Key Manager A client should automatically send a register message to the key manager at startup.
Request public key The broker should send a request_key message to the key manager at any time for the public key of any known principal.
Receive a buy or sell stock request The broker should be able to receive requests from any client. The message should be decrypted using the brokers private key
Send confirm request The server should send a confirm message to a client after receiving a buy/sell request. The message should be encrypted using the clients public key.
Receive a verify response The broker should be able to receive the verify response from the client after sending a confirm request. The message should be decrypted using the clients public key.
Send done response The broker should be able to send a done message to the client after receiving the verify request. The message should be encrypted using the broker's private key.
Exit Provide an option for the client program to quit.
Procedure:
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.
Lastly, all processes should behave sensibly when dealing with exceptional conditions.
You should use the following definition for message from a client or broker to the key manager:
typedef struct {
enum {register, request_key}
request_type; /* same size as an unsigned int */
unsigned int principal_id; /* client or broker identifier */
unsigned int public_key; /* clients or brokers RSA public key */
} principal_to_key_mesg; /* an unsigned int is 32 bits = 4 bytes */
The principal_id field should contain the clients or brokers own identifier when registering with the key manager, i.e., request_type = register.
The principal_id field should contain the identifier of the principal (client or broker) whose public key it is requesting, i.e., request_type = request_key.
You should use the following definition for message from the key manager to a client or broker:
typedef struct {
unsigned int principal_id; /* client or broker identifier */
unsigned int public_key; /* clients or brokers RSA public key */
} key_to_principal_mesg; /* an unsigned short is 16 bits = 2 bytes */
You should use the following definition for message from a client to a broker:
typedef struct {
enum {buy, sell, confirm }
request_type; /* same size as an unsigned int */
unsigned int client_id; /* client identifier */
unsigned int transaction_id; /* transaction identifier */
unsigned int num_stocks; /* number of stocks */
} client_to_broker_mesg;
You should use the following definition for message from a broker to a client:
typedef struct {
enum {confirm, done}
request_type; /* same size as an unsigned int */
unsigned int client_id; /* client identifier */
unsigned int transaction_id; /* transaction identifier */
unsigned int num_stocks; /* number of stocks */
} broker_to_client_mesg;
Step by Step Solution
There are 3 Steps involved in it
Get step-by-step solutions from verified subject matter experts
