applied-cryptography's People
Forkers
kutayzorluapplied-cryptography's Issues
Token Refresh to display updates
a token refresh (re-login) is required to view changes on the server.
Set up File encryption and infrastructure
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
Add Message Number to all messages
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)
refactoring
-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
T1: Unauthorized Token Issuance
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)
Error Codes aren't clear
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
add message number signature
Resource Folders/Files
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.
File Scrambler
write a program to randomly reorder bits stored on the file server (attack implementation)
Add HMAC to files
-concatenate key and HMAC to the end of a file on upload (before encryption)
-decrypt and verify HMAC
Add Message Number Signature
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
Message Transfer Bugs
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
Cleanup Items
-fix download issue
-allow admin to create his own password (store in the groupserver resources file)
-invalid input crashed UI
-UI input needs sanitized
Create a CryptoDriver class for future use
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
T2: Token Modification/forgery
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)
T3: Unauthorized File Servers
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.
MakeFile
With all these folders, cleanup is becoming a hassle. I'm going to write up a makefile that at least has cleanup functionality.
Edge case debugging
Finish up final testing before submission
fix async of message numbers after download
File server comm falls out of sync after download
Switch RSA to 2048
-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)
T4: Information Leaking Via Passive Monitoring
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
Hash Passwords
-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
Add HMAC to all messages
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
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.