CI(A)³ web2 security fundamentals for web3
Confidentiality, integrity, availability, authentication and authorisation have been crucial to web2 security; this article looks at how to start applying them to web3.
If you start talking about security fundamentals to fledgling or seasoned security professionals, they will usually repeat the holy trinity: “confidentiality, integrity, availability”. Authentication and authorisation are rarely mentioned, possibly because they are used interchangeably under the umbrella of access control.
Confidentiality
It was in the 19th century that the Dutch cryptographer Kerckhoff stated that the only part of a cryptography system that should be secret is the secret (private key) material itself, everything else should be public. Therefore, from whichever library generates the random number to whichever encryption, decryption algorithm is used, making this information public should not affect the security of the system. If it does, then the system was designed using the principle of security in obscurity which is the weakest, most dangerous way to build a system as its easily exploited.
The private key, however, should not be public but there have been a number of attacks on blockchains where poor key management and key hygiene were issues. A risk analysis should be performed on the key in storage, in transit and in use. The use of vaults and other custodian tooling should be used to manage keys which should offer significant improvement to using hot wallets which may themselves be poorly designed and insecure. Some use multiparty computation to generate keys but the downside to this is that you are assuming all key holders have a good level of key management skills and assumptions can be as dangerous as an active hack.
When it comes to in transit; how little, how better. A number of blockchains are moving towards the use of TEE’s (trusted execution environments) for cryptographic operations which shield the key by only performing operations in a secure environment, free from snooping and side channel attacks. However, also here a risk assessment must be performed as, for example, security auditors found vulnerabilities in Intels SGX relatively quickly after its released.
Integrity
Integrity relates to how accurate or trustworthy the data is. Anyone performing a risk analysis here needs to make sure they have classified all data and have adequate procedures for important or sensitive data. In a trustless world, blockchains rely heavily on cryptographic primitives to be able to verify the legitimacy of data. The usual process of sending transactions on blockchains requires the use of digital signatures, however, the reality is, unless a process is employed to verify the signature or the signature is handled in an insecure way, then it is just a concatenation of characters which can be manipulated. Another example is pricing information. If a protocol is heavily dependent on price information, then this data is sensitive and its integrity has to be verified especially if it is being generated by another smart contract. One solution is to use multiple oracles and analyze any anomalies between the different sources.
Availability
A number of blockchains that have fallen victim to attack appear to DoS themselves in the way they handle incidents — not having an effective incident response procedure is just as damaging because the response now appears to be “stop all transactions and then continue once we have stopped running around like headless chickens”. This usually takes some days…. Just as web2 set BC/DR metrics such as RPO and RTO, web3 companies must also have robust business continuity and disaster recovery plans that have been fully tested as well as their metrics. The web3 equivalent of an RPO should look at the potential costs of stalling or reverting transaction in a chain reorganisation. Alignment to standards such as ISO 22301 means not having to re-invent the wheel. Testing, however, should be more than table top exercises.
Access Control
One of the reasons I’m so passionate about blockchains is that the technology behind them actually solves other challenges in distributed systems. However, that’s not to say that security challenges were not solved before blockchains came into existence. One of these challenges is access control and the framework built to analyse it can be adapted to help understand how powerful functions such as those that burn, mint or transfer assets can be protected. In the framework, there is a principal wishing to perform an action. The action is to be carried out on an object. Here, we can think of the principal being an EOA or contract and the action being available through a function. There is a guard (reference monitor) which determines from an access rule, who is making the request and whether or not they have the right to perform the action on the object being guarded. This framework is split into two processes, which are attributes of the principal and the object. Authentication is the process of proving identity of the principal and once that identity has been proved, authorisation looks at what functions the principal is allowed to perform and what access to objects they have. By focusing on what a reference monitor would look like in code and what access rules could be developed for powerful functions, the threat landscape of contracts is reduced.
Authentication
Authentication deals with issues of identity and is a quality of the entity. Its the ability to answer the question “who are you and are you communicating in real time?” The need for interacting in real time is a control which, for example, mitigates the risk of signature replay attacks.
Authorisation
Authorisation is a quality of a resource such as a function which can mine or burn tokens. It answers the question “what access and actions does the identified entity have with respect to the resource.” For example, if the resource is the contract, who can perform an update?
As with my article on what web3 can learn from web2, its known principles that can be applied to improve the security of web3.
