辅导COMP90015 Security And UDP解析Java、Java调试

BitBox，RSAAUTH。

Requirement

The project makes use of Project 1. If you have not satisfactorily completed those parts from Project 1 then you’ll need to work with your tutor and lecturer to catch up.

You are required to undertake two fairly separate programming tasks:

Build a BitBox Client that can securely communicate with the BitBox peer, using public/private key cryptography
Augment the BitBox server to use UDP, in lieu of TCP, between peers

BitBox Client Port and Security

The BitBox Peer should provide a TCP port for the BitBox Client to connect, called clientPort in the configuration.properties file, as well as a comma separated list of public keys of the clients that are allowed to connect:

authorized_keys = ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCymM7yjAoXWqlMoNvrAYU2PjOWaLDDFYZt51f1VjaWq4oelhY [email#160;protected]

Note that the above key does not have newline characters, but has wrapped that way for display purposes.

The BitBox Client should read its private key from a file, bitboxclient_rsa, which for simplicity can have no password (blank password). Note that usually a client would require the user to type the password for the private key file or use an agent like ssh-agent that keeps unencrypted private keys in memory.

Challenge Response

The client opens a connection and asks to be authorized:

#123;
  quot;commandquot; : quot;AUTH_REQUESTquot;,
  quot;identityquot; : quot;[email#160;protected]quot;
#125;

The server responds with a secret key, using AES (128), encrypted with the requested identity’s public key, with appropriate padding and encoded using Base64:

#123;
  quot;commandquot; : quot;AUTH_RESPONSEquot;,
  quot;AES128quot; : [BASE64 ENCODED, ENCRYPTED SECRET KEY],
  quot;statusquot; : true,
  quot;messagequot; : quot;public key foundquot;
#125;

#123;
  quot;commandquot; : quot;AUTH_RESPONSEquot;,
  quot;statusquot; : false,
  quot;messagequot; : quot;public key not foundquot;
#125;

Secure Communication

Once a secret key has been established, all communication simply takes place using the format:

1
2
3

#123;
  quot;payloadquot; : quot;[BASE64 ENCODED, ENCRYPTED COMMAND/RESPONSE JSON STRING]quot;
#125;

Both sides need to use the shared secret key to encrypt and decrypt the messages.

Client Commands

For simplicity there will be only three commands:

list the currently connected/known peers
connect to a given peer
disconnect from a given peer

At the completion of the command the client disconnects. The commands should be executed like:

java -cp bitbox.jar unimelb.bitbox.Client -c list_peers -s server.com:3000 java -cp bitbox.jar unimelb.bitbox.Client -c connect_peer -s server.com:3000 java -cp bitbox.jar unimelb.bitbox.Client -c disconnect_peer -s server.com:3000

Examples of parsing command line options were provided in the tutorials earlier.

BitBox Peer UDP

The purpose of this part is to replace the TCP based communication layer in your BitBox Peer with a UDP based communication layer. All other aspects of the BitBox Peer operation remain the same.

In configuration.properties:

Use mode = udp or mode = tcp to indicate which mode the server should start with. If mode = tcpthen the server should operate as it does in Project 1 using TCP.
Use udpPort to indicate the port to use when starting in UDP mode.
Interpret maximumIncommingConnections as the maximum number of “remembered” peers in addition to those in the peers field.
Use the minimum of 8192 and blockSize as the actual block size for sending and receiving bytes. This ensures that no UDP message is greater than the maximum packet size.
Introduce other parameters as your implementation requires.

Handling Errors

In the case of UDP, packet loss must be accounted for. The absence of a response cannot in itself be taken as peer failure. Rather the BitBox peer must timeout ad retry some number of times, which can be a parameter introduced in the configuration.properties file, both for the timeout period and the number of retries before considering a peer to have failed.
Other aspects of the peer’s operation may be modified if needed to increase the reliability/performance, with respect to timing of request sent, in particular when the success of a given request depends on the success of previous requests.