Early Notes about GPII Architecture Security

From wiki.gpii
(Redirected from Architecture Security)
Jump to: navigation, search

This page discusses the security concerns within the Cloud4All architecture.

General security notes

This section contains some general notes on security that are relevant to the Cloud4All project. The points here will be expanded on in the next sections.

  • A software system is as secure as its weakest component. Therefore we should identify the weakest links in the architecture and think about how to strengthen them as much as possible.
  • Security comes at the expense of usability. More rigorous security mechanism usually mean more actions on the user side. Since we are developing an inclusive infrastructure, we should make sure that the level of security doesn’t make the system less accessible.
  • It would be helpful if we identify privacy rules: things which our architecture should support/not allow. Then we can check if the architecture conforms to these rules. E.g. “We don’t want the user preferences to be intercepted”
  • It would be helpful to identify a “trusted core” - a set of components that are certainly secure. Any communication with non-secure components (such as 3rd-party applications) should pass through that trusted core, which would verify the authenticity of the non-trusted components.
  • It would be helpful to identify sensitive data (username/password combination, etc.) and focus on making sure it is transmitted securely. We can afford data that is not sensitive (if any) to be transmitted insecurely if that will simplify the architecture / increase usability.

Weakest link

  • Offline components are usually the weakest part in largely online systems. In our case, the token (or any other identification information) kept on a USB stick can be stolen. If a token can be used for authentication by itself, then there’s no way for the system to distinguish whether someone is misusing a stolen token. The least we could do is to provide means to invalidate a stolen/lost token.
  • A component that pretends to be a trustworthy one, but is not (“phishing” component) would also be a weakness in the architecture if we are not able to distinguish it. One solution is to use fingerprints to identify authentic components.

GV: Not sure if off-line is the weakest. This is limited to people around you and a breech affects one person (if it is just a user). I worry more about weaknesses that affect large numbers of users including people who did nothing wrong.

GV: another TOUGH one is a device that gathers user preference info (for good or bad reasons) and then uses it for other purposes. An insurance kiosk that changes its interface to fit - but then also pulls information it uses to change rates.

Arch: A lot of the security issues are actually based on whether a user trusts a component vendor (e.g. insurance company) and are not architecture-related. We could limit these issues by allowing users to grant access to a subset of their preferences to a given app (e.g. I'm giving all my preferences to Google, but I don't want the insurance company to know anything about them). We may want to use OAuth to limit these problems. As it comes clear later, fake components are our most significant architecture concern.

Security vs. usability

  • A solution to the above-mentioned problem with the stolen token is to use it in a combination with another authentication method. This will increase the security, but severely decrease usability, as it would be more difficult for the users to identify themselves to the system.
  • Another solution to the same problem is making the token more specific, e.g. tied to a particular device or IP. Again, this decreases the usability of the system.
  • A third solution would be to have an expiry period for the token, after which it gets invalid. Brings up a usability issue.
  • A good approach for dramatically increasing application security is Google’s Two-step verification. Not sure if Cloud4All needs that level of security.

Privacy rules

  • The communication within the system should be based on anonymous tokens.
  • All sensitive data should be transmitted securely (via SSL) and as rarely as possible to minimize the risk of interception.
  • Applications should not be able to get or deduce information about the user identity (only about their settings).
  • We would like to transmit as little information as possible, not more than is actually needed (e.g. we should send only relevant settings to a given AT solution instead of the full set of user settings). Ensured by the matchmaker as it returns solution/setting pairs.
  • It should not be possible to send a lot of requests with different tokens to the preferences server in order to get people's preferences. One solution is having a long enough token to make the probability of hitting one randomly very low. If applications are reliably identifiable, then we can restrict token requests by application ID & time.
  • The system shouldn’t allow unauthorized applications to abuse the system by sending a lot of requests

Trusted core

Please note that the suggestions below for the trusted core are not final.

  • Preferences server
  • Matchmaker
  • Token Store
  • Applications (if using fingerprints)

Sensitive data

  • Any user information such as passwords, contact information, etc. is sensitive. It should be separate from the preferences, so that the two cannot be easily connected.
  • User preferences should also be sensitive. Since there is a large set of preferences, it is likely that a user can be distinguished based on their unique set of preferences. This is very difficult to avoid.
  • Tokens probably shouldn’t be considered sensitive, as they are anonymous. This would be true only if it’s hard to get user info based on their token.

Other concerns

  • The system should be protected against DoS attacks.


The current Cloud4All architecture doesn’t pose security issues different than those usually involved in a system where user information is passed along. The token-based communication should minimize the possibility of sniffing sensitive data. Using an SSL connection for encrypting the sensitive data passed should protect the privacy of the users. With that left out, the major problem left is ensuring the authenticity of the different components.