I've been given task to research blockchain implementation and its risk for my company , but I can't find this anywhere.
The answer to your question (as in a lot of questions) is: "depends on the context".
Hyperledger Fabric is very modularized, meaning a lot of things can be customized to fit your specific needs, one of the things that can be chosen is the consensus algorithm for your specific Fabric network, to learn more about this read the official documentation: https://hyperledger-fabric.readthedocs.io/en/release-1.3/blockchain.html
Currently the only consensus algorithm offered by Fabric to use on production is Kafka. Perhaps is more important in terms of security to understand that Kafka is not a Bizantine Fault Tolerance algorithm but there is work in progress to provide a BFT algorithm for Fabric in the future.
The majority attack (usually known as >50% or 51% attack) refer to the idea of one participant (individual or group) owning more than half the power of decision of what will be included in the blockchain next. This is very important to prevent on completely public decentralized networks where you don't have control at all over the participants of the network, and is more relevant to proof-of-work or proof-of-stake consensus algorithms.
Hyperledger Fabric is aimed more for private permissioned networks which means more control over the participants of the network (certain level of centralization). If your company implements an internal network were all the nodes will be part of the same organization then probably a DLT (distributed ledger technology) or blockchain technology is not the best fit. If your organization will be part of a consortium or group where they are part of the network but interact with other organizations or participants the scenario makes much more sense for a blockchain protocol depending on the use case.
Let's say your organization is part of a consortium with other 3, that makes a 4 organizations network, you can configure your Fabric network in a way that any transactions needs the approval of all the participants which makes a 51% attack impossible by design. As it is a private network the consortium controls who can become part of the network and that give more control over possible malicious participants.
Another important point is that a 51% attack is something relevant in decentralized networks with different participants that don't trust each other. In traditional networks where administrators have permissions to do things (read/write/admin) databases a 51% attack is by design is unlikely to be prevented if the participant with admin rights behave maliciously it could do it because it have rights to do it.
Finally to answer your question more directly, yes, Hyperledger Fabric could be prone to a 51% attack but it is very unlikely if the network is correctly setup and the use case makes sense for it to be used.
It ultimately depends on the consensus algorithm used. Recall that Hyperledger Fabric supports pluggable consensus.
So I will provide a more generic answer (rather than focusing on the current version of Hyperledger Fabric) since the supported consensus algorithms change and evolve over time.
If a Crash Fault Tolerant algorithm is used (like the current Kafka), then a 51% honest majority is sufficient (more precisely, n/2 + 1 nodes).
If a Byzantine Fault Tolerant algorithm is used (as PBFT in an the older version, or the future-planned BFT-smart), then a 66% honest majority is required (more precisely, 2n/3 + 1 nodes).
All of the above are the lower bounds. Some consensus algorithms require "stricter" honest majorities.
Related
It seems that both trusted computing and confidential computing can protect data in use.
Is trusted computing based on TPM and confidential computing based on Intel SGX?
Any other difference?
This is a good question since both terms are a bit ambiguous used interchangeably.
The short answer is they mean the same in most cases.
Trusted Computing was probably the term that appeared first.
It tries to put the emphasis on the reduced "trusted parties/components", called the Trusted Computing Base (TCB), that modern processor technologies as Intel SGX, AMD SEV, ARM TrustZone provide.
They all have in common that code and data are separated and protected at all times during execution in so-called Trusted Execution Environments (TEE).
Trusted Computing doesn't necessarily need to be backed by hardware features, it could also be provided by Hypervisor technologies as Hyper-V VBS or AWS Nitro Enclaves. Naturally, the TCB is bigger on such Hypervisor TEEs.
Is trusted computing based on TPM and confidential computing based on Intel SGX?
No, SGX is probably the most prominent example of trusted computing technology.
TPMs of course can also be used to establish a root-of-trust, but they typically not able to create complete TEEs for protecting data at runtime.
They are more commonly used for secure/trusted key generation and storage, or crypto calculations. To be precise a TPM is physically isolated while a TEE resides on the same chip. See also TPM vs. TEE vs. SE
Confidential Computing is a relatively new term.
It was probably established to have a bit more business-friendly term.
"Trusted" might be harder to sell than "Confidential";-)
The term puts more emphasis on the application of TEEs and tries to address a wider audience by describing not only the technologies but the applications and business cases in general.
In the words of the Confidential Computing Consortium
Confidential Computing is the protection of data in use using
hardware-based Trusted Execution Environments. Through the use of
Confidential Computing, we are now able to provide protections against
many of the threats described in the previous section.
With both terms floating around. "Confidential Computing" got much more traction and mainstream adoption, while Trusted Computing feals more niche.
Trusted Computing will probably disappear as a general term and only be used when describing hardware features and TEEs in more technical detail.
I am using a Hyperledger Fabric Blockchain.
My blockchain is "private", which means only people we accept can participate.
Right now, the blockchain is open to Internet. Is it safe ?
Should I put my Blockchain behind an API that would be in charge of Read / Write operations ?
From the "data certification" point of view, less steps between data and blockchain, the better.
Does it make sense in a security point of view ?
I don't get what you mean by blockchain being opened to internet.
If you are referring to the data structure of blocks forming a chain, it's just some files stored in peer component. If you want to discuss about it being opened, I'd rather see it as a peer component being opened to the internet.
If you manage to protect the peer component from illegal access, the only legal access Fabric provides you is through using correctly authorized certificate, so from that point on, I wouldn't worry that much.
Putting API middleware in front of the blockchain, however will provide easier interface for other users. From realistic implementation point of view, those interface will be required to some point, so it should better be protected from other security threats.
What you may want to do is to create a "standard" API for your network. This would be an app which can request for and store crypto from the CA and provides some sort of authentication mechanism to allow authorized users to then use that crypto to make requests to the network.
When you begin onboarding users to your network, you need to give them the option of using your standard API or making their own. This gives them the convenience to get started quickly by using a pre-built solution with the freedom to build their own interface into the network if they would like to.
Right now, the blockchain is open to Internet. Is it safe ?
First of all, Blockchain is secure because of its design. Blockchains stores data using certain rules that are extremely difficult for attackers to manipulate. As the numbers of block grows, it will be harder for attacker to manipulate the old block.
However, although we have a super secure blockchain system, we can't control the security of each user account or third party system.
That's why most of the security breaches in public blockchain are happening on the third party system or because of human error (not inside the blockchain).
Should I put my Blockchain behind an API that would be in charge of
Read / Write operations ?
API can be seen as a "bridge" between blockchain and us. Of course, we need this bridge to read / write Transactions to blockchain. It doesn't matter what bridge are you using, as long you can ensure the security of your bridge design.
From the "data certification" point of view, less steps between data
and blockchain, the better. Does it make sense in a security point of
view ?
One of the important aspect private blockchain is about limiting who can access into a blockchain. By limiting the user interaction, we can reduce the potential of security breach. So, the risk of having security breach can be reduced.
Background: an international company with a federation model is transforming into Microservices due to chronic Monolithic pain. Autonomous teams with quick deployment is highly desirable. In spite of theory, services are indeed dependent on each other for higher functionality, but are autonomous (independently developed and deployed). Since this is a federation model and decentralized control, we cannot impose strict rules - just like the UN. Without a governance platform that will manage dependencies else due to the multiple versions in production in different countries, we foresee uncontrollable chaos.
Let's call set of Microservices that needs to collaborate a "Compatibility Set". A service can be deployed but may not satisfy the higher functionality in its Compatibility Set. For example MicroService A-4.3 is fully autonomous, deployed and working perfectly. However to satisfy BusinessFunctionality 8.6 it must work together with MicroService B-5.4 and MicroService C-2.9. Together (A-4.3 , B-5.4 and C-2.9) they form a "Compatibility Set"
There are two approaches to this dilemma. Microservice in real life where the rubber hits the road and the learning from experience begins...
Approach 1) Governance Platform
Rationale: Federal model in an International company in 100+ countries. Which means Central IT can lay down the model but individual countries can choose their own destiny - and they frequently do. It frequently devolves to chaos and the Central IT team is on the hook. DDD is the solution for an ideal world where version inconsistencies do not derail functionality like releasing services which do not fit into the Compatibility set, individually blameless but together they fall apart or result in flawed or inconsistent functionality.
There is no homogeneity, there isn't even standardization of terminology
Developers are mixed skill, many junior, and many learning reactive programming and cloud native technologies
Bounded Context heavily depends on Shared Vocabulary and it can get subtle, but this is impossible to enforce and naive to assume in an International, mixed skill, fragmented scenario with multiple versions running
Standardization on a Single Business Model is not realistic in such a heterogeneous system (but ideal)
How what is Central IT to do when they're held responsible for this Chaos?
Enforce a Governance Platform
Create a Microservices governance system or framework to enforce dependency management. It verifies and enforces at design and run time dependencies on a particular Microservice through a manifest and performs some checks and balances to verify the service implementations being offered - the "Compatibility Set".
Approach 2) Domain Driven Design (DDD)
DDD is about modelling domains that are constantly evolving, where domain experts (typically a business stakeholder, or perhaps an analyst) will work alongside developers to design the system. Within each domain, a ubiquitous language is formed, such that within that context, the same word always means the same thing. An important thing to realise is that in one part of your system, “Order” might mean one thing, it might mean for example a list of products. In another part of your system, “Order” might mean something else, it might mean a financial transaction that happened. This is where the model you describe can fall down, if my service needs to get a list of orders, perhaps there is a capability out there that supplies a list of orders, but which orders are they? The list of products or the financial transaction? Trying to coordinate as many developers as you have to all use the same language here is an impossible task that is doomed to fail.
In DDD, rather than trying to manage this at a system level and force every service to use the same definition of Order, DDD embraces the inherent complexity in coordinating very large deployments with huge numbers of developers involved, and allows each team to work independently, coordinating with other teams as needed, not through some centralised dependency management system. The term used in DDD is bounded contexts, where in one context, Order means one thing, and in another bounded context, Order can mean another thing. These contexts can function truly autonomously – you describe your services as being autonomous, but if they have to match their definition of order with the entire system by registering and supplied dependencies to a central registry, then really they are tightly coupled to the rest of the system and what it considers an order to be – you end up with all the painful coupling of a monolith, with all the pain of building a distributed system, and you won’t realise many of the benefits of microservices if you try to take this approach.
So a DDD based approach doesn’t ever try to take a heavy handed approach of enforcing dependencies or capabilities at the system level, rather, it allows individual teams to work without needing central coordination, if Service A needs to interact with Service B, then the team who manages Service A will work with the team that manages service B, they can build an interface between their bounded contexts, and come to an agreement on language for that interface. It is up to these teams to manage their dependencies with each other, at the system level things can remain quite opaque / unenforced.
Too often we see people implement “Microservices” but end up with a system that is just as, if not more inflexible, and often more fragile, than a monolith. Also called a "Minilith" or "Monolith 2.0" Microservices require a complete rethink of architecture and software development processes, and require not just allowing services to be autonomous and independently managed, but also for teams to be independent, not centrally managed. Centralising the management of dependencies and capabilities in a system is likely to be an inhibitor to successfully building a microservice based system.
Intelligent and Pragmatic comments invited...
Approach 1 (Governance) is pragmatic and tactical and intended to solve very real challenges. Question is - will it undermine the long term strategic DDD model of the Enterprise?
Approach 2 (DDD) is ideal and aspirational but doesn't address the very real challenges that we have to deal with right now.
Opinions? Thought? Comments?
I've seen multi-national companies try to cooperate on a project (or be controlled from a central IT team) and it's a nightmare. This response is highly subjective to what I've personally read and seen, so it's just my opinion, it's probably not everyone's opinion. Generally broad questions aren't encouraged on Stack Overflow as they attract highly opinionated answers.
I'd say DDD probably isn't the answer. You'd need a large number of a developers to buy into the DDD idea. If you don't have that buy-in then (unless you have a team of exceptionally self-motivated people) you'll see the developers try to build the new system on-top of the existing database.
I'd also argue that microservices aren't the answer. Companies that have used microservices to their advantage are essentially using them to compartmentalise their code into small, stacks of individually running services/apps that each do a single job. These microservices (from the success stories I've seen) tend to be loosely coupled. I imagine that if you have a large number of services that are highly coupled, then you've still got the spaghetti aspects of a monolith, but one that's spread out over a network.
It sounds like you just need a well architected system, designed to your specific needs. I agree that using DDD would be great, but is it a realistic goal across a multi-national project?
I also dealt with the problem described in the question. And I came up with an approach in which I use API-definitions like OpenAPI-definitions to check compatibility between two services. The API-definitions must be attached as metadata to each service and therefore it is possible to do the check at run and design time. Important is that the API-definitions are part of the metadata as well when the API is offered and when the API is used. With tools like Swagger-Diff or OpenAPI-Diff it is possible to do the compatibility-check automated.
I know the concept of building a simple P2P network without any server. My problems is with securing the network. The network should have some administrative nodes. So there are two kinds of nodes:
Nodes with privileges
Nodes without privileges
The first question is: Can I assign some nodes more rights than others, like the privileges to send a broadcast message?
How can I secure the network of modified nodes that are trying to get privileges?
I'm really interested in answers and resources than can help me. It is important to me to understand this, and I'm happy to add further information if anything is unclear.
You seem lost, and I used to do research in this area, so I'll take a shot. I feel this question is borderline off-topic, but I tend to error toward leaving things open.
See the P2P networks Chord, CAN, Tapestry, and Pastry for examples of P2P networks as well as psuedo-code. These works are all based off distributed hash tables (DHTs) and have been around for over 10 years now. Many of them have open source implementations you can use.
As for "privileged nodes", your question contradicts itself. You want a P2P network, but you also want nodes with more rights than others. By definition, your network is no longer P2P because peers are no longer equally privileged.
Your question points to trust within P2P networks - a problem that academics have focused on since the introduction of (DHTs). I feel that no satisfactory answer has been found yet that solves all problems in all cases. Here are a few approaches which will help you:
(1) Bitcoin addresses malicious users by forcing all users within their network do perform computationally intensive work. For any member to forge bitcoins that would need more computational power than everyone to prove they had done more work than everyone else.
(2) Give privileges based on reputation. You can calculate reputation in any number of ways. One simple example - for each transaction in your system (file sent, database look up, piece of work done), the requester sends a signed acknowledgement (using private/public keys) to the sender. Each peer can then present the accumulation of their signed acknowledgements to any other peer. Any peer who has accumulated N acknowledgements (you determine N) has more privileges.
(3) Own a central server that hands out privileges. This one is the simplest and you get to determine what trust means for you. You're handing it out.
That's the skinny version - good luck.
I'm guessing that the administrative nodes are different from normal nodes by being able to tell other nodes what to do (and the regular nodes should obey).
You have to give the admin nodes some kind of way to prove themselves that can be verified by other nodes but not forged by them (like a policeman's ID). The Most standard way I can think of is by using TLS certificates.
In (very) short, you create couples of files called key and certificate. The key is secret and belongs to one identity, and the certificate is public.
You create a CA certificate, and distribute it to all of your nodes.
Using that CA, you create "administrative node" certificates, one for each administrative node.
When issuing a command, an administrative node presents its certificate to the "regular" node. The regular node, using the CA certificate you provided beforehand, can make sure the administrative node is genuine (because the certificate was actually signed by the CA), and it's OK to do as it asks.
Pros:
TLS/SSL is used by many other products to create a secure tunnel, preventing "man in the
middle" attacks and
impersonations
There are ready-to-use libraries and sample projects for TLS/SSL in practically every language, from .net to C.
There are revocation lists, to "cancel" certificates that have been stolen (although you'll have to find a way to distribute these)
Certificate verification is offline - a node needs no external resources (except for the CA certificate) for verification
Cons:
Since SSL/TLS is a widely-used system, there are many tools to exploit misconfigured / old clients / servers
There are some exploits found in such libraries (e.g. "heartbleed"), so you might need to patch your software a lot.
This solution still requires some serious coding, but it's usually better to rely on an existing and proven system than to go around inventing your own.
This question already has answers here:
Peer to Peer: Methods of Finding Peers
(13 answers)
Closed 7 years ago.
Simple question. How does client connect to a p2p system if it does not know any already connected nodes? Is it event possible? Like in torrent magnet links, or pastry?
Yes, it is possible. One technique is to use a well-known URL, where the peer can fetch a list of IP addresses of (bootstrap/central) peers currently reachable online. Another technique is to send a multicast message on the LAN and hope that another peer on the same LAN is already connected to the P2P network. Then, addresses of other peers can be fetched from it.
There is an academic paper on this subject which is quite interesting. Addressing the P2P bootstrap problem for small overlay networks 2010 by David Isaac Wolinsky, Pierre St. Juste, P. Oscar Boykin, and Renato Figueiredo.
It explores using already existing P2P-services (like XMPP, BitTorrent, Gnutella, and Brunet) for bootstrapping smaller, private overlays.
This is the abstract:
"P2P overlays provide a framework for building distributed applications consisting of few to many resources with features including self-configuration, scalability, and resilience to node failures. Such systems have been successfully adopted in large-scale services for content delivery networks, file sharing, and data storage. In small-scale systems, they can be useful to address privacy concerns and for network applications that lack dedicated servers. The bootstrap problem, finding an existing peer in the overlay, remains a challenge to enabling these services for small-scale P2P systems. In large networks, the solution to the bootstrap problem has been the use of dedicated services, though creating and maintaining these systems requires expertise and resources, which constrain their usefulness and make them unappealing for small-scale systems. This paper surveys and summarizes requirements that allow peers potentially constrained by network connectivity to bootstrap small-scale overlays through the use of existing public overlays. In order to support bootstrapping, a public overlay must support the following requirements: a method for reflection in order to obtain publicly reachable addresses, so peers behind network address translators and firewalls can receive incoming connection requests; communication relaying to share public addresses and communicate when direct communication is not feasible; and rendezvous for discovering remote peers, when the overlay lacks stable membership. After presenting a survey of various public overlays, we identify two overlays that match the requirements: XMPP overlays, such as Google Talk and Live Journal Talk, and Brunet, a structured overlay based upon Symphony. We present qualitative experiences with prototypes that demonstrate the ability to bootstrap small-scale private structured overlays from public Brunet or XMPP infrastructures."