johnhof / applied-cryptography Goto Github PK

a token refresh (re-login) is required to view changes on the server.

ADRESSES: File Leakage

-have each user store a group->keylist map
-have the Group Server store a group->key
-when sending files to a file server, the user should encrypt both the keyID, and the file. sending them as a files (it sends {gkID,F}Kgk)
-the File Server should treat all files as if they aren't encrypted
-the any group member should be able to set change the group server key associated with the group (another message handler)
-the user should store all of the old keys as well as the new ones sent by the groupserver, meaning they decrypt old files

ADRESSES: Message replay, reorder

-have each server generate a (secure) random message number, store it, and return it to the client
-have the client store the message number (as well as any file server)
-every message should send message number+n

Implementation notes
-the message number should be checked only once at the beginning of the request loop, NOT in every message handler (like token)

-edit groupserver and fileserver classes to mirror one another
-encapsulate cripto implementation in classes (ie, abstract from the flow of the threads)
-possibly encapsulate message handling and responses for each type of message into their own functions
*at least modularize them to prevent unnecessary code

Due to the fact that clients are untrusted, we must protect against the threat of illegitimate clients requesting tokens from the group server. Your implementation must ensure that all clients are authenticated in a secure manner prior to issuing them tokens. That is, we want to ensure that Alice cannot request and receive Bob's security token from the group server.

-create an interaction mirroring the one in the writeup (key exchange/password sending, etc)
-create a method of on server password storage and retrieval (hashing/salt)

the error code returned are too generic. Inform the user what went wrong

John: I believe this is what the TA meant. phil can verify

This is more of a general thought. I think each new instance of a user should spawn its own resource folder/file. It should be associated with the username, and loaded if that user's file already exists. that way we can easily store server public keys that each user might need. The same thing could be done for each instance of a server, since that server will need to store its own public key for future user during authentication.

write a program to randomly reorder bits stored on the file server (attack implementation)

-concatenate key and HMAC to the end of a file on upload (before encryption)
-decrypt and verify HMAC

ADRESSES: token theft

-have the user generate, and store an RSA key pair at the start of each session
-send the server the public key during login
-change the GroupServer to add the user public key to the token (must be added to UserToken)
-The user should include a signature of the message number ONLY during setup
-the both Servers should check the signature against the public key stored in the token
-this will require an extra message during setup to the server to verify the token belongs to the user

We arent sending any of our important message information (Token, message number, etc) during the chunk sending for upload and download. This doesnt matter a whole lot right now, but if another group discovers it in the next phase, they can break our shit pretty easily

-fix download issue
-allow admin to create his own password (store in the groupserver resources file)
-invalid input crashed UI
-UI input needs sanitized

make a Crypto driver to wrap ugly crypto processes and allow for cleaner server/userside code.

-getRSAKeyPair()
returns key pair
-getAESKey()
returns key
-encryptAES(data, key)
returns encrypted data
-encryptRSA(data, key)
returns encrypted data
-decryptAES(data, key)
returns decrypted data
-decryptRSA(data, key)
returns decrypted data
-signRSA(data, key)
returns signature
-verifyRSASignature(data, key, signature)
returns boolean

possible utility functions:
serialize
deserialize

Users are expected to attempt to modify their tokens to increase their access rights, and to attempt to create forged tokens. Your implementation of the UserToken interface must be extended to allow file servers (or anyone else) to determine whether a token is in fact valid. Specifically, it must be possible for a third-party to verify that a token was in fact issued by a trusted group server and was not modified after issuance.

-create a function to get the signature of the token based on its contents (within the token class)
*it is important that the signature is on the data in the token, not the token itself
*the signature will be stored and accessed using the token itself
-create a method of public key retrieval from the group server
-add a signature check of the token before fileServer allows any action to be taken
-set the groupServer to gen a new key every day (or some other fixed ammount of time)
*store and distribute the previous days key as well
-allow a token to be verified using either todays, or yesterdays key

additions:

UserToken
-signature object
-void sign(key)
-boolean verify(key)
GoupServer
-current and previous key pair
-some method of timeout to generate an save the new key
-port and functionality which doles out the current public key
-sign all tokens before sending
FileServer
-check signature before
-recheck the key from groupserver once a day (or at least some set timeperiod)

The above trust model assumes that properly authenticated file servers are guaranteed to behave as expected. In order for this guarantee to mean anything, your implementation must ensure that if a user attempts to contact some server, s, then they actually connect to s and not some other server s, then they actually connect to s, and some other server s'.

Note that any user may run a file server. As such, the group server is not required to know
about all file servers. Your mechanism for enabling users to authenticate le servers should
require communication between only the user and the file server, and possibly client-side
application con figuration changes. Hint: you may wish to look into how SSH allows user
to authenticate servers.

as always, follow the diagram.
NOTE: stored asymmetric keys should be 2048, NOT 1024. This includes both stored group server and file server keys.

With all these folders, cleanup is becoming a hassle. I'm going to write up a makefile that at least has cleanup functionality.

Finish up final testing before submission

File server comm falls out of sync after download

-pretty self explanatory, it should only require a simple change in the CrytpoEngine
-worst case, it will require us to change the AES en/decryption procedure

*extra karma for trying to shorten the nasty looking AES key functions located in Client, and ServerThread (longer key means more data can be encrypted... I think)

Since our trust model assumes the existence of passive attackers (e.g., nosy administrators), you must ensure that all communications between your client and server applications are hidden from outside observers.This will ensure that file contents remain private, and that tokens cannot be stolen in transit

encrypt all sensitive data before sending:
-look at diagram for login process
-look at diagram for initial fileServer/User interactoin
-encrypt all subsequent data with a shared AES key

-if a password is being set, salt hash it with SHA1 and only store the hash
-each login attempt will salt and hash the sent password and compare it to the one on the list

IMPLEMENTATION:
-create a SHA1 wrapper {hashWithSHA(byte [])} in CryptoEngine
-change the password setting and checking procedures in GroupThread to utilize the function

ADRESSES: modification

-add an HMAC function to CryptoEngine
-the HMAC key should be sent by the user during setup, stored by both parties
-attach an HMAC to the end of every message (must include all data except the HMAC)
-have both servers and client check the HMAC before executing requests

*extra karma for finding a way to check the HMAC once, like we do with the tokens signature, rather than inside every request handler