Security

Problems and concerns

1. Docker - is our current configuration secure enough? How can we additionally encourage use to not use docker as superuser? What can we improve in Docker configuration
   1. Docker containers + GPU requiring privileged mode
2. How can we checked that received data (computation results) are safe? Can someone hide malicious code inside image? Can you hide it inside LuxRender .flm file (which is binary)?
   1. What techniques of defense-in-depth are available and realistic on Windows for Golem, Blender and LuxRenderer?
3. Storing and using users private keys - how can we manage this? We should also remember that most of our users may have different private key for other cryptocurrencies stored on the same machine/
4. Checking source code that is called inside Docker. Is the approach from this PR enough (https://github.com/golemfactory/golem/pull/801 - running source code defined by local environment) or do we want to hardcoded rendernig scripts in docker?
5. General application architecture and its weak spots.
6. New architecture idea with web interface and communication via websockets - what are the weak points here and how can we secure it.
7. Signing and encryption of network messages - but taking into account that we want to replace current p2p network with Devp2p and it's authentication and encryption methods: https://github.com/golemfactory/golem/pull/801/files
8. Potential idea: sandbox feasibility (i.e. chromium sandbox) for task computation)
9. Task result encryption (AES CBC)

Possible attacks:

• Attacks on Golem Network
• Attacks on Golem Network users
• Attacks on external resources that Golem Network uses
• Attacks on other computers with Golem network

Identified attacks:

• DoS
• DDoS
• Sending harmful code as a task - potential solutions:
  • Really good sandboxing (minimal priorities)
  • AppRegistry with Certification system (user check the code)
  • Whitelists - you can only run code from trusted providers
• Sending harmful files as resources - potential solutions:
  • Don't run files sent as resources or results as binaries without sandboxing
• P2P network data contamination
• Sybil attack see P2P security
• Getting access to other users private keys - potential solutions:
  • Private key is only save localy, never send to the network.
  • Is save in encrypted form.
• Google attack - coordinated attack on the network by a large corporation or entity controlling vast amounts of computing power / storage space.
• Sending many low value tasks to choke up the network - to prevent this attack we need a) good network topology and reputation system that may prevent not paying for tasks for a long time, b)limits on the number of saved tasks, especially number of saved tasks from one requestor.
• Getting out of sandbox - see Docker security and VM security

Key components

From our FAQ:

Every new technology is exposed to attacks, especially, new and unpredicted ones. All components of Golem application will be designed to be robust to the attacks.

Key security elements will be:

• computation taking place in isolated environments with minimal privileges and lack of external network connectivity.
• Well-known safety cryptography based on elliptic curves.
• Signed and encrypted messages inside the Golem network ensuring authenticity, which protects against man-in-the-middle attacks and passive data collection.
• Reputation system helping to detect malicious nodes and mitigate them and additionally evaluating metrics to assist in secure, efficient and correct task routing.
• Whitelist and blacklist mechanisms allowing providers to build trust networks and run only applications prepared by trusted developers.
• Together, the application registry and transaction framework mitigates Sybil and whitewashing attacks by providing an incentive to participate, introducing an economic and computational cost to participation, and providing a metric for reputation in order to maintain optimal connectivity.
• The Ethereum integration and transaction framework makes possible custom payment-based security mechanisms, eg. escrows, deposits, insurance and audit proofs.
• Security audits will be conducted for every release, performed by external contractors.

Cryptoeconomy basics

• Nobody can control more than 25% of computational power (directly or with payoffs).
• Nobody can have more than 25% of funds in the network.
• Network can change dynamically with nodes connecting and disconnecting.
• Generation of huge amount of IP is easy and cheap.
• In each network there are altruistic users and malicious users, but most user are ecnomicaly rational.