Architecture

Goals and Principals

We found a problem that we believe to be very common, and our goal is to provide a solution that is simple to use, private, and secure. Every time the three words: simplicity, privacy, and security; appear in the requirements of a problem, solving that problem is immediately a big challenge. We have taken on that challenge and we believe to have came up with solution that has a very good balance between easy of use and security.

Your information, regardless of whatever it is, is your information and you should have full control of what information you share and with who you share it. We strongly believe that a user should never be forced to trade is privacy for convenience. We designed and engineered Group Bank with this principal in mind, therefore, user privacy and security are a big deal for us.

Keeping Information Private

Keeping the information of the users private is one of the main goals of Group Bank. We don't want to have the ability to access the information of the user at any time. However for Group Bank to be able to minimize the number of transactions required to settle the debts within a group it needs to access some of information about the transactions: the amount and the identification of the parties involved. You are probably thinking right now: "but that is almost all of the most relevant and private information regarding a transaction". That is true. We could solve this problem by protecting the users and not providing any identifiable information such as IP addresses or email addresses. However, for the service to work correctly we need to be able to identify who owes money to who and force that person to pay his that. So this solution is no good.

To solve the issue we designed the system based on the fundamental ideas of segregation of duties and knowledge segregation. The idea is to split the responsibility (and ability) to identify the users and the responsibility (and ability) to store and access the transactions. One entity is responsible to identify the user and therefore has knows some identifiable information about the user, and other separate and not related entity is responsible to store and manage the transactions but it only knows the users by their ID (see section User Authentication) which can not use to trace back to the actual user by itself.

The system is comprised with three components: the group server, the main server, and the proxy server. The group server is the one responsible for the identification of the users, but without any knowledge of the transaction history. The main server is core of the Group Bank service, it is the one storing the transaction history and the one who performs the computations necessary to minimize the number of transactions required to settle a debt within a group. However, this last server does not know any identifiable information about the user just a random number that identifies the user within the system but with which the main server is not able to identify the people behind the transactions. As things are right now, there is still a way for the main server to identify a user, and that is through its IP address. This issue can be solved in multiple ways: the cooler way would be for the user to communicate with the server through the TOR network, which provides complete anonymity to the user. The other would be using a proxy server that is not related in any way to the main server manager and which does not relay the IP address of the user. With the use of a proxy server the main server would see only the IP address of the proxy server a never the user's.

The use of a proxy server does not imply that the user establishes an HTTPS connection with the proxy server, which in turn establishes another HTTPS connection with the main server and just forwards the messages. No, this is no good, since the proxy server would have access to the information in the transactions. Instead we establish an HTTPS connection with the main server with the proxy server working as a man in the middle. Of course, we know that HTTPS protects all information against man in the middle attacks an, therefore, the proxy server would not have access to any of the information in the transactions. The only information the proxy server knows is that a user with some IP address made a request to the main server.

This strategy works very well if the server managers don't collude with each other. The main server should be managed by a stranger, since group members know everyone's identity. Imagine it as public service, like GitHub. If it's large enough it won't risk its reputation by colluding with someone only to get a single group's information. We argue that it won't even care enough about a single group's information anyway

User Authentication

We do not use a standard username and password scheme to authenticate the user, moreover we never establish an authenticated session between the user and the servers. Instead we rely on the authentication capability of RSA to authenticate the users with both the group and the main servers. Please refer to RSA Usage to check how we actually use RSA to sign and verify.

When a user is created it generates a public key and a private key. The public key is used as the user identifier and must be unique for every user. All members of the group may have access to this key, including the group server and the main server. The private key is kept stored locally, encrypted with a secure password. This keys is NEVER shared with anyone and never sent through the network!

There is never a session established between the users and any of the servers. Consequently, the users need to identify themselves every time they make a request. They accomplish this by appending their ID to the request they send to the server. When the servers receive the request, since both the group and the main server keep a record of the registered IDs, they can check their databases and to see if the received ID is registered. However, just claiming to be user C1 does not prove that I am user C1. I need to prove I really am user C1. We accomplish this by having the users sign every request they make and send both the request and its signature to the servers. The servers can then check the signature and confirm that the user claiming to be user C1 really is user C1. Actually what the server is checking is if a user claiming to be the user with public key C1 knows the private key corresponding to C1. For this reason the private key should never be shared with anyone!

Non-Repudiation

An important question to have is "Can a user claim the server forged something in his name?" A user that owed money might feel inclined to claim that a transaction was forged and that he doesn't owe it. Sure, since it's probably a group of friends this is unlikely, but the system should still prevent such claims. So what prevents a user from doing it?

Signatures! We take advantage of the power of RSA to prevent repuditory behavior. The way it works is: since only the user has access to its private key, he is the only one able to digitally sign any message with that key, therefore, any message signed with his private key (signature) could only have been signed by that user. With this in mind, we force all transactions to be signed by each user involved. Thus, preventing a user from claiming, later on, that he/she did not accept the transaction.

The servers themselves also have RSA keys, so that the servers also cannot repudiate certain messages (like proving a user was accepted into the group, in case the group server owner decides to delete the user from it's records because he owes him a lot of money).

In short, every entity involved in the system will hold RSA keys and signatures are used in pretty much every action.