Architecture : Thoughts on Security Architecture for Enterprise(Permission’d) Blockchain Applications
The intent of this article is to explore security architecture thoughts for enterprise Blockchain implementations.
At the outset, one should recognize that some form of trust should exist for enterprise blockchain models to work — unlike for public blockchains. The concept of some trust, sets the business context for the rest of the security architecture for enterprise blockchains. However, as with most security architecture exercises, it is critical to decompose the technology and understand the common vulnerabilities before developing a security architecture or a set of controls
Decomposing the Blockchain technology — Architecture & Constraints: From first principles, blockchains (aka crypto ledgers) are data store constructs and are at times similar to link lists. However, they differ from link lists because the blocks are securely linked (referenced) and distributed on peer-to-peer (P2P) network nodes. Unlike traditional link lists, the reference is the hash of the previous block and not a pointer to the next. This hashed link is essentially the Merkle Tree value which embodies all the hashed values from the current block to the root or genesis block. However, the most significant difference is that blockchain formation and the distribution of blocks across the P2P nodes is supported by a consensus protocol. This protocol computationally verifies the hash of prior blocks before new blocks are added to the blockchain. In some cases, the protocol may incentivize the verifying node or miner. Like most protocols (e.g. OSPF routing protocol), the consensus protocol is inherently responsible for maintaining the “state” of the blockchain. The consensus aspect of the protocol is — form a consensus amongst the verifying nodes to add blocks.
The distributed and P2P network nature of blockchains leads to three implementation scenarios. These are:
– Private; or
– Hybrid blockchains.
In the public model, there are no restrictions on who can become a member node (permission-less) and leverage the public internet. While private blockchains also leverage the internet, the number of nodes and who can become a member node is restricted (permission’d). Enterprise blockchains are a hybrid model which is permission’d and the P2P network may or may not leverage the internet. Theoretically, some peers could interface with the internet.
Public and private blockchains are built on the premise of decentralizing all compute and storage services to support the creation of blocks on peer-to-peer networks. In other words, the concept of a traditional server running one or more applications does not exist. Every node in a public blockchain contributes to server-side services. Likewise, a traditional client does not exist and every node is also a client. However, in an enterprise blockchain there is some amount of centralization of services and as such, nodes can have designated functions to provide some centralized and pre-defined server- side services, e.g. allowing nodes to join or be designated validators or miners to publish transactions into the distributed blockchain [1,2,3]. Interestingly, the Enterprise Ethereum Alliance (EEA) has released an Enterprise Ethereum Client Specification as well .
Unlike traditional (web 2.0) applications with a web presentation layer, an application layer and a data layer, Blockchain technology typically has only two layers. That is, the application architecture is tightly coupled and almost monolithic. It typically consists of the web presentation layer and application layer. This tight coupling of the web presentation layer with the application layer poses challenges for programming extensibility.
In enterprise or permissioned blockchains, the centralization of services allows for not just extensibility but also the adding of additional architectural components to support centralization. For instance, additional databases to store static content such as information about the nodes, users etc. or produce analytics on the state of blockchain may be supported. In this model and from the lens of architectural patterns, the blockchain is one component of a larger system or a system of systems and the high-level architecture is as illustrated in the figure below.
Figure 1: High Level blockchain application architecture
To provide context, the table below lists some of the common frameworks, tools etc. for each of the above layers.
Common Vulnerabilities: Based on the above architecture, the common vulnerabilities occur at the smart contract level, blockchain processing platform (e.g. EVM) and blockchain protocol  and described in the table below:
From the table above, it is interesting to note that the Smart Contracts and Blockchain Processing Platform vulnerability exploits are related to inconsistent business logic and algorithm flow, while the blockchain protocol vulnerability exploits are related to mining.
Considerations for Security Architectures: Based on the above discussion and in the context of defence-in-depth, any Security Architecture should be configured in layers. One approach to the security architecture layers is along the lines of the application architecture illustrated in the figure 1. Accordingly, security architecture is illustrated below:
Figure 2: Blockchain Security Architecture
Presentation Layer Security: At the very least, the front-end application security should ensure the following:
a) Define an appropriate Digital Identity Model: A Digital identity is a unique representation of a physical subject (person or thing) engaged in a digital transaction. Identity-proofing, or enrolment, is the physical or digital process of verifying a subject’s association with their real-world identity. An identity model and its associated identity proofing should provide reasonable assurance for the identity claimed by the subject. When the trust attributes of the Blockchain application ranges from trust-less (public) to total/strong trust (enterprise, consortium or private), it is good practice to have multiple assurance levels for identity- proofing.
Typically, two or three identity models such as public (anonymous), trusted, partially trusted should suffice. Typically, a subject will transition from the “applicant” state to the “subscriber” state when some level of identity proofing is complete with an identity model assignment, issuance of an account (login/username) and authentication credentials defined. A word of caution, identity proofing should not be confused with Authentication.
Security guidance NIST.SP.800–63–3 .
b) Define an appropriate Authentication Model: Post identify-proofing, a subject is no longer an applicant and during authentication, a subject is a subscriber. Authentication is the assertions by a subject (subscriber) to prove identity. The assertions (aka authenticators and factors) are:
i) Something that one has to (access card)
ii) Something one knows (password) and
iii) Something one is (biometric).
Authentication mechanisms should be commensurate with the strength of the identity model, the level of access and the sensitivity of the transaction. When multiple authenticators are combined (aka Multifactor Authentication) should be implemented. Security Guidance NIST.SP.800–63-A, B, C .
c) Define an appropriate Authorization Model: Authorization (aka permissions, entitlements etc.) is the process by which to establish the right to perform transactions (actions) and claim access to assets and resources by a subscriber. In a Blockchain application, the Authorization model should link to the Identity Model and Authentication Model. A good practice is to develop a multidimensional matrix of the account associated with identity, authentication and authorization. For example, an anonymous identity has access to X, Y, Z types of transaction (actions e.g. transact online only with single factor authenticator, transact offline with multifactor authenticator etc.) and with A, B, C types of authenticators respectively. This type of authorization model will leave room for evolution into Attribute- based Access Control and Role-based Access Control at the application level and ultimately at the organizational level for consortium or private Blockchain applications. The authorization model will typically address concepts such as Separation of Duties (SoD). Security Guidance NIST.SP.800–63-A, B, C.
d) As with all Security processes for enterprise (consortium) or private applications, access control should be managed from a lifecycle perspective to ensure robust cyber hygiene. It is recommended that the Access Control family policy from NIST SP-800–53  be addressed.
e) Additionally, the Security Functional Requirements for Access Control Guidance  and Identity testing from OWASP  should also be considered. These are the following:
· Can anyone register for access?
· Are registrations vetted by a human prior to provisioning, or are they automatically granted if the criteria are met (KYC and AML)?
· Can the same person or identity register multiple times?
· Can users register for different roles or permissions?
· What proof of identity is required for a registration to be successful?
· Can identity information be easily forged or faked?
· Can the exchange of identity information be manipulated during registration?
· Can authentication be bypassed?
· Is there any verification, vetting and authorization of provisioning requests?
· Is there any verification, vetting and authorization of de-provisioning requests?
· Can an administrator provision other administrators or only users?
· Can an administrator or other user provision accounts with privileges greater than their own?
· Can an administrator or user de-provision themselves?
· How are the files or resources owned by the de-provisioned user managed? Are they deleted? Is access transferred?
f) Key & Certificate Management: Typically, three types of keys and (or) certificates are at play in blockchains. These are used for enrolment, transactions and for TLS. In terms of key and certificate management, the NIST publication (SP 800–57) outlines Recommendations for Key Management and should be considered.
g) Web Application Security: Web application security should include protections against vulnerabilities identified in OWASP Top 20. Additionally, the NIST publication (SP 800–70 Revision 3) outlines checklists for IT product development and should be considered .
Application Layer Security: At the very least, the application security should ensure the following:
a.) Smart Contracts and Blockchain Processing Platform are vetted to prevent calls to the unknown, valueless (gasless) send, exception disorders, type casts, re-entrants, keeping secrets, immutable bugs, value (ether) lost in transfer and stack size limit. These should be addressed through standard software testing techniques and Smart Contract analyzers such as Oyente and static code analysis on Go Lang (https://golang.org/cmd/vet/)
b.) Blockchain protocols should be vetted to prevent the blockchain from not converging as expected or into an unpredictable state, safeguarding the seed (genesis) block and ensuring timestamps are adequately protected.
Network Layer Security: Depending on the nature of the application and the type of network (internet-based, leased lines, virtual private network), appropriate controls should be extracted from the System and Communications Protection family of NIST SP 800–53 Revision 4. At the very least controls related to boundary protection (data-in-motion) and denial of service (DoS) should be considered.
Acknowledgements: Thank you to the blockchain team at PomeGran for providing insights. Also, a special thank you to the larger blockchain community across the globe.