Security Decision Model
Disclaimer: This is a summary of patterns we have observed during our research and should not be considered any form of technical or investment advice. Also, the given “known examples” do not imply they are the best implementations of the said pattern or any superior to any other implementation of the pattern not listed.
Security is a cross-cutting concern that is applicable throughout the application. Security patterns are applicable at different layers ranging from blockchain infrastructure to smart contract layers. Also, patterns are used for different purposes, like authentication and key management. Therefore, We derived two decision models for authentication and authorization.
Authentication Decision Model
Authentication in blockchains makes sure an identity or its account is what it claims to be. An identity is defined as a set of attributes related to an entity. Several authentication patterns can be used to manage identities in blockchains. The authentication decision model is illustrated in Figure 1. Only the on-chain patterns are discussed.
Figure 1: Authentication Decision Model.
An identifier is a unique persistent string that can uniquely identify an entity. The mapping between identifiers and the corresponding identity data attributes can be registered in an identifier registry on the blockchain. Decentralized identifiers (DID) is a widely adopted standard in SSI projects. A DID needs to be resolved when in use. Thus, maintaining a shared registry of DIDs improves the system interoperability, as the identifier registry can be used as the resolver for DIDs from different blockchains.
However, the use of a single identifier for all the transactions from different applications may lead to privacy issues, as the associated public key could be linked to expose information about the user and his/her behaviour. Multiple registration complements the first pattern, where it allows a user to have a separate identifier for each application or role. Such a design can isolate interactions with one party from another, minimizing the potential to link identities. The multiple identifiers can be registered in the identifier registry. Key loss or compromise is an issue when an identity has a single public-private key pair to authenticate transactions from the user. Conversely, update by delegates pattern also complements the first pattern and allows an identifier to be associated with a list of recovery delegates that could manipulate the corresponding identity on behalf of its owner. If the key is lost, the user could update the identity with a new key pair with approval from the delegates.
Authorization Decision Model
Figure 2 is a graphical representation of the corresponding decision model. Smart contracts deployed on the blockchain are accessible to all participants of the blockchain platform. Thus, a permission-less function can be triggered by any user.
Figure 2: Authentication Decision Model.
The embedded permission pattern can be applied to a smart contract to provide function-level authorization. When a transaction invokes a smart contract function, the authorization of the caller to execute the function is validated before executing the rest of the contract logic.
For each function invocation, several authorization patterns providing different levels of flexibility and cost could be used. If only a single authority (in the form of a blockchain account) is allowed to authorize an activity, the single authorization pattern could be used. Sometimes, we may also want to use m-of-n (m ≤ n) multi-signatures to define the number of authorities required to authorize a transaction. This is useful when more than one authority is required to authorize an activity or when a subset of authorities are unavailable at the time of authorization. In such cases, multiple authorization pattern provides more flexibility by enabling a set of blockchain accounts to authorize a function call. Although this pattern allows flexible binding between the function call and authorities from a larger set of blockchain accounts, all valid authorities still need to be defined in the smart contract.
When the authority to authorize an activity is not known in advance, the off-chain secret enabled dynamic authorization pattern could be used. The function call being authorized is defined with a hash value of an off-chain secret such as a random string. Whoever knows this off-chain secret could then authorize the function call by revealing the secret using a transaction. The smart contract can then compare the predefined hash with the hash computed from the secret to determine the authorization. One constraint of this pattern is that the off-chain secret cannot be reused once revealed in a transaction. As the off-chain secret could be used on different blockchain platforms simultaneously, this pattern improves the interoperability, e.g., atomic swap across blockchains. The last three authorization patterns complement the first pattern. Similar to before, other existing authorization patterns could be applied to the context of blockchain-based applications, e.g., delegated access control.