6.3.4. Potential Security Vulnerabilities

Every registered instance of the decentralized solutions is normally assigned with a blockchain node and an account of which a key pair could be generated and assigned to registered instances for their storage and management. Key pairs are required to validate and send transactions with its local blockchain node via the chosen blockchain client protocol. The same key pair could be retrieved and utilized over and over again without a concept of proper key rotation and management, and it is possible that the key pair could be compromised and thus the aforementioned attacks could still be made possible to create vulnerabilities and threats to the decentralized solutions.

Following the compromised key secrets, *distributed denial of service* (DDoS) could also be made possible as long as the blockchain node is hosted with enough computation resource, and it is possible to spam the blockchain network with a huge amount of transactions to be processed. The denial-of-service attack could also be performed by any malicious registered node, though they are part of the supply chain industry. A distributed key managemen<sup>t</sup> module with key rotation functionalities to store and manage the key secrets should be implemented in the decentralized solutions, and a security authentication layer should also be added on top of the key managemen<sup>t</sup> module whenever the blockchain interface, owned by the same registered instance, retrieves the key pair.

While for the data of product records stored and processed on decentralized components of decentralized solutions, such as the smart contracts deployed to the blockchain network and the service instance of any distributed file storage implemented, any blockchain node assigned to the registered entities could interpret and retrieve product record subsets if requested. The retrieval of product records is possible only if the unique identifier of processed products is supplied, as these product record subsets stored with the deployed smart contracts might not be encrypted and obfuscated with any hash algorithms. Though application of data security is really dependent on which types of blockchain network and consensus algorithm are adopted, which could generally categorized either into "*permissioned*" or "*permissionless*", the decentralized solutions could adopt. Any data stored and processed on any decentralized system component should be kept minimum, obfuscated, and even encrypted to prevent from any potential malicious manipulation.

The publicity of the smart contract source code could also cause security vulnerabilities. Unlike the source code of different system components in NAS, which has the option to have its code base open-sourced or completely privatized, the smart contract code of decentralized solutions is always open and easily accessible by blockchain nodes running on the same network. Malicious users of the decentralized solutions running blockchain nodes could therefore look for human-induced vulnerabilities if any method of the deployed smart contracts is not implemented correctly.
