brightid/brightid-node

A node hosting the BrightID social graph

www.brightid.org

Unique Human Identity

BrightID allows you to prove to applications that you're only using one account.

• No personal data or biometrics are used for verification.
• Verified by a trusted group of close personal contacts plus a decentralized graph database.
• A lost or compromised ID can be replaced by reconnecting with a few close personal contacts.

Decentralized & Nonintrusive

The network consists of volunteers running nodes. Nodes host the social graph used for verification, but there's no personal information stored there.

Mobile App

ID creation and connections to people and apps are managed through the BrightID mobile app.

Contribute

Contributions to translations are welcome through weblate.

• Project board
• All BrightID repos
• More information on contributing may be found in our Github Wiki.
• Apply to our keybase to talk with other contributors.

Integrating BrightID in your Project

• API spec and guides for developers integrating BrightID.
• See also the BrightID Node repo.

brightid-node's Issues

Catalog Known Attacks

Keep a catalog of known attacks with example graphs, so that those who want to evaluate the anti-sybil algorithm don't repeat past efforts.

Provide enough detail to the anti-sybil algorithm so that it can be created in code.

Here for now https://docs.google.com/document/d/1Zk1qLUBWWdXk1gKNJ4jUHMcFyyoq-ZIj6tM6s0D1D-k/edit#heading=h.hvfdqv5g9gkw

Tune ArangoDB/foxx

For example:

maximum number of memory mappings per process is 65530, which seems too low. it is recommended to set it to at least 128000.
execute sudo sysctl -w "vm.max_map_count=128000"

--server.threads (64) is more than eight times the number of cores (2), this might overload the server

See also https://docs.arangodb.com/3.4/Manual/Programs/Arangod/Server.html

Add Diagrams to P2P doc

https://docs.google.com/document/d/1T-YtCuTzeRmOzfktCAibd9vsp2hISp8SZG4rBzZx_FU/edit

Eligible group returned fails to join

A group is returned by fetchUserInfo as an eligible group, but fails a PUT to membership with a 403.

See BrightID/BrightID#285

Brightside Node API reference

From @adamstallard on November 8, 2017 7:2

https://github.com/Brightside-Social/brightside-node/wiki/API-Reference

Copied from original issue: BrightID/BrightID#4

Rate limit all endpoints to prevent DOS / DDOS

Can be done in nginx

Add diagrams to anti-sybil doc

When two users connect, scores displayed and transferred should come from nodes

When scores come from the device, they can be faked. The score should come from one or more nodes trusted by the user viewing the score. Viewing another connection's score is important to preventing social engineering attacks. See BrightID/BrightID#240

Allow anti-sybil code to run on a node

The code will need to use our actual graph DB that's being used for users, groups, and connections

Create regular DB dumps

Authorize other apps

Users should be able to authorize other apps using BrightID.

Lets say app A wants to use BrightID as its authentication method or just wants to allow its users to connect their BrightID to the app. We need to support 3 scenarios:

1- app A on an another device like PC and BrightID on phone
2- app A as a mobile app on same device as BrightID
3- app A as a web-based app on same device as BrightID

We can use a solution same as what we are doing for making connections now:

1- app A can send a message to BrightID using qr-code(scenario 1) or Deep Link(scenarios 2,3) and also upload data(avatar, name of the app, ...) as an encrypted message to a server same as what we have for connections now

More details about Deep Links:
https://en.wikipedia.org/wiki/Mobile_deep_linking

Deep link for BrightID could be something like this:

BrightID://authorize?data=encrypted_data

Both IOS and Android support Deep Links and we can use something like this to implement it on React:
https://reactnavigation.org/docs/en/deep-linking.html

2- BrightID will sign the message and upload data(avatar, name, score, ...) to the server

3- app A can use web sockets or retry again and again to get the data and check the signature to validate the user

Modeling how groups improve trust scores.

API call to fetchUserInfo should return updated connections list with updated scores

Return a list of all connections with their current scores.

Create different datasets for no-groups test.

DB integration to Foxx app

Code our anti-sybil algorithm

Return a user's score or score estimate from user-info API endpoint

API method to get a user's score by public key

Anti-Sybil Proposal Document

https://docs.google.com/document/d/1sIpRxH6k1eWwb_KImNa-QF35g5VP28UHrMUX6L6fyvA/edit?usp=sharing

"Membership" API endpoint (put/delete) for joining/unjoining a group

package/installer

From @adamstallard on November 10, 2017 6:36

Package for installation:

arangodb
node.js backend

Copied from original issue: BrightID/BrightID#6

Backup operation sets

related to #38

Outline the anti-sybil attack strategies that need to be tested

Create test platform for testing different anti-sybil algorithms

This should include the ability to parameterize the creation of the trust graph (including sybil and honest regions) according to the parameters in the anti-sybil doc https://docs.google.com/document/d/1sIpRxH6k1eWwb_KImNa-QF35g5VP28UHrMUX6L6fyvA/edit?usp=sharing

whitepaper

Should include

• Anti-sybil approach
• P2P design
• Short Mobile UI walkthrough

Add TTL for objects uploaded to the profile service

We don't want to keep an encrypted profile upload forever, only long enough for the other user to retrieve it.

Host ArangoDB/Foxx Backend

Use https://github.com/Brightside-Social/brightside-node/wiki/Development-Guide for help (up to "foxx initial deployment")

Conduct tests of anti-sybil strategies using our algorithm and others

Add Collections to DB to support Groups

Allow docker image builds to be triggered from dockerhub

I created new repos in dockerhub

https://hub.docker.com/r/brightid/

that can be built from the dockerhub website, for example
https://hub.docker.com/r/brightid/brightid-node.web_services/~/settings/automated-builds/

We could add these to the docker compose file

Protect against DOS attacks that spam new connections

1. rate limit ip addresses that are creating many new accounts
2. rate limit connections where neither user is verified
3. rate limit connections per user (no one needs to create 10,000 connections a day)

Add references to anti-sybil doc

I just put in random numbers when I knew I was referring to something I read. It would be good to have references to the actual papers.

https://docs.google.com/document/d/1sIpRxH6k1eWwb_KImNa-QF35g5VP28UHrMUX6L6fyvA/edit?usp=sharing

Node Dockerfile

Create different datasets for cut-region test.

users API endpoint

See BrightID/BrightID#23

Store original, signed operations into an "operation set" in the DB for use by P2P and backups

Operation sets are the original signed operations that precede changes to the DB. We need to store all operations with their timestamps and signatures so that they can be sent to other nodes to re-verify them.

See the whitepaper section on operation forwarding.

Assigning scores

The scores for each group in SybilGroupRank need to be converted into something that makes sense.

The sybilRank paper says this

an
OSN cannot simply identify a pivot in the ranked list below
which all nodes are fake, and it still has to rely on
manual inspection.

but they are considering graphs that already exist. If we look at how the graph changes between iterations--starting from a graph that is completely honest, we can assign probabilities to ranges, by assuming that honest users can improve their scores, while sybils can't.

New users can start with low scores, but they can improve. We can find good probability boundaries by making the assumption that sybils' scores won't improve.

Rather than storing scores twice, we can store just the raw ranks from sybilGroupRank, and then store a mapping that sets the probability boundaries (there could be 10 or 100 boundaries, for instance). These boundaries are adjusted after each iteration of sybilGroupRank. To get a group's score requires looking up the raw ranks, looking up the boundary map, and making the conversion at query time.

Foxx Application

From @adamstallard on November 10, 2017 6:31

Copied from original issue: BrightID/BrightID#5

Check timestamps on more API calls to avoid replay attacks

As a working example, PUT and DELETE calls to /connections check the timestamp from the most recent PUT or DELETE operation and only update it if the timestamp is newer. It uses the 'removed' collection to record timestamps to DELETE /connections operations.

If we want the timestamps included in calls to
PUT /membership
DELETE /membership
POST /groups
DELETE /groups
POST /fetchUserInfo
to be useful, we need to store previous timestamps in the DB and do similar checks

Otherwise replay attacks are possible, e.g. I can repeatedly remove someone from a group if they left it at some point in the past and rejoined; I can fetchUserInfo for another user.

Installation Instructions

Instructions for installing/configuring ArangoDB, Foxx and our Foxx Application, which is what we need for the MVP

https://github.com/Brightside-Social/brightside-node/wiki/Installation-Instructions

"Groups" API endpoint (post/delete) for creating/deleting a group

Make gap between scores configurable

Right now there is a gap between 10 and 90. Let's close the gap while still making it obvious.

@UBIpromoter suggested 70 and 30.

The idea is to make it possible to make more obvious progress without needing to cross the gap.

Separate profile service and backend API web service into separate containers

Currently there is one directory and one dockerfile for both web services. https://github.com/BrightID/BrightID-Node/tree/master/web_services

The two services are unrelated and should be in a separate container for each.

Downloadable application for simulating sybil attacks

I was thinking today about how other people can easily run simulations to help us improve our anti-sybil system.

I really like the web-based sybil attack simulator you built.

We are going to start taking regular backups (dumps) of the graph. What I would like is for any user to run the sybil attack simulator on a recent dump of the graph. If the graph starts getting too big, we can create a utility that dumps smaller subsets of the graph to make a simulation more manageable.

I think we could use the same stack: html, javascript, python, but create an installer (or docker solution) that runs everything locally on a user's machine. The application can know where to download graph dumps from a site where we host them.

This way a user can experiment with different graphs loaded from arangodb running on their own machine. Multiple users can operate on different graphs without bogging down our test machine with having to load multiple copies (dumps) of the graph in arangodb.

We can offer bounties to users that submit a simulation that leads to an improvement in the anti-sybil system.

Recheck group eligibilities for both users after a connection is made.

Take a list of seeds (or seed groups) to use as input

Add Groups Support to API

Dockerfiles

We'll need dockerfiles for

1. nginx (to act as a reverse proxy, limiting access to endpoints on the arangodb port)
2. arangodb, including configuring foxx

Expose fewer ports to the host from docker

Right now, ports 8529 (arangodb) and 3000 (profile service) are exposed to the host network. These should be blocked by a firewall running on the host, but it's safer to not even expose them to the host, but only to other containers. This can be done by removing the network_mode: host directive and changing the use of ports in https://github.com/BrightID/BrightID-Node/blob/master/docker-compose.yml to expose so that only the other containers have access to those ports. Then use container names in urls as described in https://docs.docker.com/compose/networking/

For example, in

https://github.com/BrightID/BrightID-Node/blob/master/web_services/brightid-nginx.conf#L65

proxy_pass http://127.0.0.1:8529/_db/_system/brightid/;

could be changed to

proxy_pass http://db:8529/_db/_system/brightid/;

The web container (nginx) is the only container that needs its port (80) exposed to the host network, so network mode host is fine there.