Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Bitvote Update Sybil Security Approach Summary
To whom it may concern,
Here's a BitVote update and the low down concerning the Sybil security issue '1-per-ID' aka '1 person per 1 ID'
You'll be happy to hear that we're sorted on the technical side, thanks to the great minds of Ethereum :). They've pretty much got all the important tech aspects sorted: vote chain, decentralised system and scalability. What we do, however, need help with is a more complicated problem: the ID system. As shown by the recent leaked celeb pics, ID fraud through social engineering is in fact a more concerning problem than ID fraud through technical engineering.
Since BitVote derives the value of votes from scarcity, vote units won't be trusted to have that value if anybody is able to double their vote hours through using multiple IDs – this would be a sybil attack achieved through social engineering. So our mission at the moment is to find social oriented professionals – sociologists, political students, social engineer hackers, activists, doctors, etc. – to help us make sure that voters can only have 1 ID per person without compromising their anonymity or alienating anybody. In other words, protecting BitVote from Sybil attacks, which are often of ‘social nature’.
Here are the caveats:
- We don't need or want to know who the voter is, only that each voter is unique
- We don't want to alienate technophobes
- It doesn't have to be a perfect solution; there is almost always a margin of error when voting on any given topic
- There can be more than one method; the combination of multiple techniques can make a stronger system
- Users can have options. If method A to verify your identity doesn't suit you, you can use method B, etc.
- BitVote is designed to be self-healing which means that every BitVoter has the opportunity to use their own BitVotes to identify problems, purpose new solutions and help execute updates to the BitVote system, including the 1-per-ID module
- The method has to be inter-changeable because even if there is a suitable solution to prove 1-per-ID now, this method might not work in the future due to the evolving nature of technology.
Here are a few approach plans the team has been speaking about to give you a better idea. Please note that a lot of them are far from ideal as they contradict some of the fundamental principles of BitVote. They are listed here for inspiration – hopefully they will kickstart some thoughts on finding a perfect solution!
Method 1: ID Pools
Although it's hard to say what technological attacks may be possible in the future, an idea by Vlad Zamfir of Ethereum and Aaron Bale is to work with ID pools. Everybody using BitVote at the same time belongs to such an ID pool and – instead of doing an annoying screen CAPTCHA – would have to do a 'fun test' simultaneously to validate their identity. This could be a (crypto) game, which would normally take about five minutes to play, but would have to be completed in ten minutes. The user thus has enough time to play comfortably, but not enough time to play it on two computers. If everybody in the same ID pool is playing the game simultaneously, the user can be identified as unique but remains anonymous. The chances of manipulating the 1-per-ID system decrease drastically, as even if somebody manages to play the game on two computers (margin of error), there’s no way anybody will manage to play it on three computers, etc thus look limiting the threat.
- This method is one of the most efficient ways to decrease the threat of multiple IDs
- It's not inconceivable to do and there are many uses for this idea (e.g. Universal Basic Income is also looking for a way to protect themselves from Sybil attacks), not just BitVote.
- After some time, it will be possible to create a robot that can play these games. This means that there would have to be a team of game developers who would constantly have to come up with new tests. This is expensive.
- Existing technology would have to be adapted to work for games, which require a constant input. At the moment it only works for a fixed input. This takes time and is also expensive.
- Technophobes might get annoyed because they don’t enjoy playing games.
Method 2: ID through reputation
This system would only be used to get the project started and test the user experience, as it contradicts the fundamental principles of BitVote. The system would learn user traits and behaviour, for example how many Facebook friends or Twitter accounts they have.
- It’s an easy option to get a test version up and running quickly
Anonymity is not given – we're basically stalking the voters!
It would alienate technophobes who only log onto the internet once in a while because they might be wrongly identified as sock puppets
It can be manipulated
Method 3: Active Authentication
BehavioSec and DARPA (Defense Research Project Agency) are working on ‘active authentication’, an identification system that goes beyond passwords. Similar to the many twirls on a person’s finger, a user’s ‘keyboard style’ can be identified as unique. Nobody types at the same speed or moves the mouse in exactly the same way when connected with other variables, such as how your eyes track the screen and usage statistics. This way, the system could identify a user’s uniqueness ‘in the background’, without the use of a password. Here’s a video for further clarification: http://www.youtube.com/watch?v=fgNpOzvwOiU
- The user doesn’t have to remember a password
- It’s an existing system that could be repurposed for BitVote
- The Cyber Grand Challenge is aimed at improving a fully automatic network defence system
- About 75 % accuracy
- We’re making the computer aware of who’s at the keyboard, again a concern might be that the machine is ‘stalking users’. This information doesn’t have to be stored though.
Method 4: Oath of Confidentiality
There is a way to legally prove that a person is authentic yet anonymous. Doctors, legal workers and journalists use it to validate that information has been received by a real person but the identity of this person has to be protected. This is done by a ‘trusted authenticator’ who has access to information that identifies the individual who needs to be protected as unique. The ‘authenticator’ abides by an oath of confidentiality to ensure that the information is not disclosed. Example: http://www.doctorswithoutborders.org/
- It’s an existing system that’s relatively easy to implement
- A human being would have to be trusted to validate the identity without disclosing information. Manipulation is thus a risk.
- The authenticator could decide to stop protecting the confidential information for a variety of reasons. For example, a moral obligation to expose a wrongdoing might override the oath of confidentiality.
Method 5: Google+ ‘Real Name’ Policy
Google+ aims to maintain that profiles are for individual people. Users are encouraged to use their real names, those names can only be changed a limited number of times and ‘pretending to be someone else’ could have your profile suspended. Google’s interest in identifying unique users could be combined with BitVote’s to create a stronger system. See here for more information: http://support.google.com/plus/bin/answer.py?hl=en&answer=1228271
- Google might have the resources to develop a secure ID system, to get them on board would therefore be beneficial Cons:
- In the wake of massive privacy violations by big corporations, Google’s trustworthiness might be questioned by some BitVote users
Method 6: Validation through SIMcards
Everybody has to register a SIMcard before using it and the chances of someone having more than two phones is relatively low. Even if many SIMcards are acquired specifically to manipulate a BitVote, the demographics – i.e. a million votes from China on an obviously favourable cause – could indicate fraudulent behaviour.
- It’s easy to do as it uses an existing system Cons:
- It can be manipulated because you can register more than one SIMcard
In the beginning, OpenVote will be accessible through IRC protocol, through a mandatory secure SSL connection. To further ensure fairness in voting, all votes will be securely live fed into a ‘Looking Glass’ through HTTPS. Furthermore, to prevent DDoS all IP addresses of servers will be effectively hidden through the extensive use of reverse-proxies not only with IRC but also with the Looking Glass. Team Y is responsible for advancing the technical security and accessibility of the Record protocol in correspondence with OpenVote.
Sybil security is a common concern. Banking professionals care a lot about password security protocols, doctors have to pass HIPAA law requirements before disclosing information and security online in general is – as you know – a highly anticipated goal. If you have any ideas or people you could put us in contact with regarding this issue it would be of immense help – not only to BitVote!