TODO
Plan
- [DONE] Users and authentication
- [DONE] asym. keypair generation on the client
- [DONE] gotta detect registration on the client, generate asym. keys, generate master
key from password, intercept registration and send the extra data to the server
- [DONE] we cannot simply use
accounts-ui
because Accounts.onCreateUser is only called
on the server side, thus we need to roll our own login code and intercept the
registration form being submitted
- [DONE] gotta have login/register views selected through a button
- [DONE] gotta include username next to email in registration
- [DONE] derived master key on login and on registration
- [DONE] generate and encrypt asymmetric keypair
- [DONE] gotta display login/register errors
- [DONE] derive a content key (for encrypting profiles, photo albums and wall posts)
- [DONE] Profiles
- [DONE] add profile form for editing profile
- [DONE] encrypt profile changes with symmetric key
- [DONE] sign profile changes with private key
- [DONE] Friending
- [DONE] friend keys
- [DONE] key exchange by simple generation (no DH initially, maybe later)
- [DONE] ECDH key exchange was quite simple to implement, and way easier than storing
and managing an additional public key pair that would be used for encryption - Friend request table and acceptance/notifications
- [DONE] Friend notifications and accepting/rejecting them
- Security: The Meteor web server should not allow a friended person who hasn't accepted to read the content key? Otherwise, we would have to reset the content key when someone rejects a friend request. Or we would have to only add friended users to ACL when we know they accepted... which complicates the code and I'm lazy to do that.
- [DONE] ACL trees for sharing content key w/ friends
- Make sure you test:
- creating bigger ACL trees
- adding/removing repeatedly (same & different user)
- getting all content keys and making sure verNo = # of content keys
- [DONE] Merkle trees over ACL tree
- [NOPE] Actually (I think) ACL tree is implicitly authenticated by the authenticated
encryption scheme used to encrypt the keys along the tree paths, and by a signature on
the root key
- Defriending
- Merkle trees over friend lists
- defriend (
=>
merkle tree update)
- signatures
- might not need friend list if we just use an ACL tree to represent the friend list
- [DONE] ACL trees
- [DONE] User profiles
- [DONE] One ACL tree for the profile key and album key and wall key
- [DONE] Individual ACL trees for conversation keys (which are different)
- [DONE] User albums
- [DONE] User walls
- [DONE] User conversations
- NOT DONE: one on one convos can use the friend key
- [DONE] group convos need to use an ACL tree
- Optimizations for verifying Merkle trees? Looks like we don't need the hashes on the path, we
just need the co-path hashes and then we compute stating from the leaves the hashes on the path
and verify that they end in the root.
Authentication
- Figure out how to enable SSL for Meteor apps
- Alin: I already know how to generate a CA certificate, server-side keypair, and a certificate for it
- Figure out if Meteor uses SRP for authentication and how session management works
- Must figure out how Meteor stores passwords on the server side
- Need to make sure passwords are not plaintexts
- Need to make sure we use a different KDF on the client for deriving the user's master key
- We don't want the user's master key being equal to the password hash on the server. Otherwise, the server would know our key.
- Figure out which PAKE scheme to use for in-person friending
- Figure out how SRP works and if it's viable to use it for client authentication by the server (it's a zero-knowledge password proof system, so attacker gets just one guess per authentication attempt)
- https://github.com/meteor/meteor/blob/master/packages/srp/srp_tests.js#L9
- https://github.com/meteor/meteor/blob/master/packages/srp/srp.js
- https://github.com/jedp/node-srp
- SRP:
- http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.104.9653
- http://srp.stanford.edu/ndss.html#secactivedict
- http://srp.stanford.edu/doc.html
Meteor
- Seems like Meteor re-renders templates that are in
if
blocks even when the if condition is false, so my code queries a DB with a non-existent UID and returns a NULL result. Maybe this can be fixed.
- Figure out how Meteor persists user data on the backend. For ACL trees, storing trees in a database is not terribly efficient, maybe Meteor will let us do something better?
JavaScript libraries
- need an scrypt() implementation in JS for implementing the client-side KDF
- might need ECC primitives for fast asymmetric crypto. SJCL (https://bitwiseshiftleft.github.io/sjcl/doc/) seems to have an ECC class but god knows about its security?
- can look at Mylar paper and code. They might use ECC in their JS code.
Testing
We'll probably need to write our own Meteor clients in JavaScript?
* split server/client code into server.js and client.js
* write test code that includes server.js, creates a bunch of users, logs in as one and starts posting messages, uploading pictures, revoking access etc.
* how can we write a test that simulates multiple clients interacting with the meteor server at the same time?