Proton Blockchain – “The Payment Blockchain” is a software blockchain developed by Metallicus, Inc., based on the foundation of EOSIO which identifies itself as having advantages over blockchain solutions due to its Speed, unique Identity ID, Signing system, and Fee structure.
During the initial phase of the project, we recognized that the main code base is comprised of a fork of the EOSIO block chain project with the tag v1.9.1.
This code was de-scoped from the assessment as we recognized that the EOSIO project is well used and therefore was essentially previously reviewed. The project did use the forked version in the Proton Chain repository as a reference when needed.
In this post, we will talk specifically about the work we performed as part of our security assessment for the Metallicus team. For a more in-depth overview of Proton and its roadmap, you can read about it on the Proton blog.
The source code for the project was supplied by Metallicus through the GitHub repository at https://github.com/ProtonProtocol and specifically under the proton.contracts project.
The assessment was conducted by the Kudelski Security Team, with the tests taking place in the 4th Quarter of 2020 and focused on the following objectives:
- Perform manual source code review of C++ and other used languages
- Perform review of smart contract platform for security vulnerabilities and logic errors
- Perform review of third-party libraries used in systems
- Perform analysis of any custom encryption used in development of platform and verification of third-party encryption libraries
- Analyze the contracts layer in the proton contracts to ensure that the logic is sound, that there are no security issues, and that the platform is free from vulnerabilities
A separate engagement, also performed in the 4th Quarter of 2020 was a review of the Proton Swap tool, which is a tool allows users to swap an XPR based on the Ethereum blockchain to mainnet XPR – which opens all other functions of the Proton Blockchain.
The findings during the review were less than many of our other projects of similar size and complexity, with the findings being mostly initialization issues, arithmetic operational checks, resource allocation and code clarity on permission checks.
We believe that the reason for the rather low severity of the findings is due to the detailed threat modeling, discussion, and walkthroughs with the core development team. In addition, detailed security assessments have been performed on EOSIO and that also contributed to a lack of findings, but we recommended to the project team that they continue to monitor bug fixes on the EOSIO core and incorporate those updates and bug fixes.
In this code assessment, we performed the following tasks:
- Security analysis and architecture review of the original protocol
- Review of the code written for the project
- Assessment of the cryptographic primitives used
- Compliance of the code with the provided technical documentation
The review for this project was performed using manual methods and utilizing the experience of the reviewer. No dynamic testing was performed, only the use of custom-built scripts and tools were used to assist the reviewer during the testing.
Code Safety
We analyzed the provided code, checking for issues related to the following categories:
- General code safety and susceptibility to known issues
- Poor coding practices and unsafe behavior
- Leakage of secrets or other sensitive data through memory mismanagement
- Susceptibility to misuse and system errors
- Error management and logging
Cryptography
We analyzed the cryptographic primitives and components as well as their implementation. We checked in particular:
- Matching of the proper cryptographic primitives to the desired cryptographic functionality needed
- Security level of cryptographic primitives and their respective parameters (key lengths, etc.)
- Safety of the randomness generation in general as well as in the case of failure
- Safety of key management
- Assessment of proper security definitions and compliance to use cases
- Checking for known vulnerabilities in the primitives used
Technical Specification Matching
We analyzed the provided documentation and checked that the code matches the specification. We checked for things such as:
- Proper implementation of the documented protocol phases
- Proper error handling
- Adherence to the protocol logical description
As a result of this assessment, we did not find any critical shortcomings in the reviewed components.
Metallicus quickly patched all the problems we identified and let us review their changes to confirm their effectiveness.
Notice that we did not find any evidence of malicious intent, flawed logic or potential backdoors in the codebase.
We would like to thank Metallicus, Inc. for trusting us, for their availability and the pleasant collaboration throughout the assessment!
Kudelski Security Research 
One comment