With the current trends in the ever-growing market of the Crypto Industry, it is very likely that there are hundreds of ICO’s that have made their way into the mainstream. And with the recent incidents of Crypto Exchanges getting hacked leading to a loss of more than half a Billion in total, it is High Time and very necessary that these Companies protect the interest of their customers, investors, and the company itself. Making the security to be the need of the hour.
As the Crypto Industry is still in its infancy, there still needs to be a lot of reforms that need to be implemented with respect to the Security of its assets. After a thorough analysis of nearly 120 exchanges and newly created ICO’s, we realized that its an alarming signal for the Crypto Companies that they do not make it up to have even the basic levels of Security being implemented.
And, hence we also bumped into one of the Open Checklists that is available on the internet for the Crypto Companies to implement a checklist for securing their assets. Here’s our blog post summary of the Security Standards for the Crypto Companies that we have listed below.
A digital asset designed to work as a medium of exchange that uses cryptography to secure its transactions, to control the creation of additional units, and to verify the transfer of assets. In many cases it is anonymous.
CRYPTOGRAPHIC ASSET MANAGEMENT
- KEY/SEED GENERATION:
This point covers the generation of cryptographic keys and seeds that will be used within a cryptocurrency system. Confidentiality and Un-guessable numbers are the two things required for the secure creation of cryptographic keys and seeds.
Confidentiality is to ensure that the newly created keys or seeds are not read or copied by an unauthorized person.
Un-guessable numbers are required to ensure the newly created key cannot be guessed or determined by an unauthorized person.
So the creation of Key or Seed should be confidential and un-guessed manner.
- Operator created Key / Seed.
- Creation methodology is validated.
- DRBG compliance.
- Entropy tool.
The cryptographic keys and seeds are created by the person who will be using it. This is to protect the confidentiality of the key. Any system which requires a person to transfer a key or seed to another one after generating it will fail to achieve Level 1, with the exception of the initial configuration of an automated signing agent.
In some situations where an automated agent will make use of a cryptographic keys/seed, it is recommended that the administrator of that system generate the key/seed on a suitable offline system with good entropy, have this key/seed transferred securely onto the target device, and then securely deleted using CCSS-compliant data sanitization techniques to protect the confidentiality.
Transferring a cryptographic secret for backup purposes does not violate the same person requirement, however, those secrets must be transmitted and stored in a strongly encrypted format.
The seed or key generation methodology is validated prior to use. Software that is used to generate seeds should be free from any features that restrict the generated seed to conform to deterministic values and features that store or transmit the generated seed to another person.
Once you are done with auditing of software, a digital signature should be generated and published. This signature also should be validated prior to each execution to ensure that the software has not been altered since it passed its security audit.
Sometimes keys or seed are created without the use of software, the creation methodology must be validated to ensure determinism is not present.
The key or seed is generated using a Deterministic Random Bit Generator (DRBG) that conforms to NIST SP 800-90A, and has been seeded with at least two separate cryptographically secure sources of entropy have been combined in a secure manner. NIST SP 800-90A is a standard which ensures that deterministically-generated numbers follow a random distribution with respect to a deterministic seed. Thus, the ability to determine these random numbers is reducible to the ability to discover the DRBG’s seed.
The Dual_EC DRBG from NIST SP 800-90A has been demonstrated to be vulnerable so should not be used.
The key or seed can also be generated by a Non-deterministic Random Bit Generator (NRBG), instead of Instead of a NIST SP 800-90A or a True Random Number Generator (TRNG) that clears the industry standard statistical test for randomness.
- WALLET CREATION:
Here it covers about the creation of wallets or addresses that can receive cryptocurrencies. Wallets are created using key signing methodologies that requires a single key’s signature, multiple keys signature or a minimum number of signatures from many keys. And in another way also wallets can be created individually, or in a deterministic way that allows a set of addresses or key pairs to be created from a single master seed. Security of wallet creation is derived from the integrity of the wallet in the face of various risks such as lost or stolen or compromised key.
Backups of cryptographic keys or seeds must be stored with the use of strong encryption when not in use. If backups use a less-secure mechanism than the key or seed itself then the system cannot be certified as Level 3. Backups are resistant to electromagnetic pulses which induce currents in electronics and damage the data stored within. To secure against this risk is to store a seed or key on paper, wood, metal or on other non-digital media, or place the digital medium within a sealed faraday bag designed to protect contents from electromagnetic interference.
- Key Usage:
This Section focuses on the use of cryptographic keys and/or seeds to make sure that they are used securely to minimize the risk of the integrity of funds and confidentiality of the private key. The number of risks is associated with the keys – which can lead to loss of funds, malware can copy or modify the key, or unauthorized access by an insider.
- Key access always requires the user/pass/nth factor
- keys should be only used in a trusted environment
- Operator ID and references should be checked
- Operator background should be checked
- No 2 keys should be used in a single device
- follow DRBG compliance
To access primary key, one should provide identification ID like – (username or email ID and should) and at least 2 other factors for authentication.
All keys should only be used in a trusted environment. This avoids from malware copying the key. It also helps to protect the access of key from other users on the system.
The track record and trustworthiness of the person should be checked before handing over the Organization’s key.
No 2 master keys of the same multi-wallet should be present in the same device.
Digital signatures should always use unique ‘k‘ value that never repeats. This can be achieved by adopting Deterministic Random Bit Generator (DRBG).
All the employees who hold the organizational key should undergo the identification verification.
Fund destination and the amount should be checked manually before using the key.
- Key Compromise Protocol (KCP):
This section deals with the KCP (Key Compromise Protocol) which deals with actions that must be taken in the event of key or its Operator/holder is compromised. Every organization should be ready to handle the situation where the key is compromised. Proper policies and procedures should be followed to handle this situation. Using KCP is one such example.
- KCP should be implemented
- Training should be given and KCP and should be rehearsed regularly
An inventory of all keys should be maintained and awareness should be there about which keys are critical for the successful operation
KCP should be regularly tested for its viability. staffs should be properly trained and updated with the changes.
- Keyholder Grant/Revoke Policies & Procedures :
This part covers the policies and procedures surrounding granting and revoking access to cryptographic keys or seeds that store organizational or end-user funds. Staffs typically have greater access to an information system with respect to accessing its information, invoking privileges- restricted actions, and representing the organization to the public. If management of the onboarding and offboarding personnel is not proper then it leads to risks of privileged accounts remaining when staffs depart, as well as unrevoked keys that persist signing the authority for certain transactions.
- Grant or revoke procedures.
- Requests made via an authenticated communication channel.
- Grant or revoke audit trail.
An awareness of how roles should be managed when onboarding and offboarding staff from keyholder positions exists within the organization.
The organization maintains checklists that cover all tasks that must be completed when staff vacates or transition into keyholder roles within the organization. These checklists have been reviewed by a knowledgeable person to ensure least privilege principles are applied to the information system, as well as necessary access where required. This eliminates the risks associated with missed privileges and the possession of un-revoked keys.
Checklists of the organisation include auditing information that records the identity of the staff member that performs the grant/revoke operations. Each entity within the audit trail is attested to by the staff member who performed that task.
- SECURITY AUDITS / PENTESTS
This part covers third-party reviews of the security systems, controls in technical, and policies that protect the information system from all forms of risk as well as penetration and vulnerability tests designed to identify paths around existing controls.
Regardless of the technical skills, knowledge, and experience of the staff who maintain and build an information system. It has been shown to be true by third person reviews very frequently identify risks and control dependencies that were failed to see by the staff (miscalculated). To resolve these kinds of issues companies require different people to test a product from those who write it, different people than those who implement a cryptocurrency system should access its security.
- Security audit.
A developer should have knowledge about Bitcoin security. So, having the knowledge available during the design and implementation stages helps ensure best practices are followed to minimize risk.
A single audit / pentesting are performed by a third-party entity prior to or shortly after the launch. The audit covers both static and dynamic analysis of source code to ensure secure programming patterns were used whenever applicable and cryptographic libraries were used properly whenever they have been employed. Doing audits decreases the risks associated with institutional blindness and provide confidence in the organization’s controls and procedures.
Security audits should be conducted in an organization at least once in a year, and documentation exists that shows how each of the concerns within the audit was addressed. Regular audits/penetration testing not only reduces the overall cost of security, not only risk in security.
- DATA SANITIZATION POLICY(DSP):
This aspect covers the removal of cryptographic keys from digital media. Removal of cryptographic keys from digital media is very important because using some digital forensic technique; an attacker can get the data that has been deleted. We should make sure that all the keys are properly removed. This eliminates the risk of data leakage from decommissioned devices.
- DSP exists.
- Audit trail of all media sanitization.
Staffs should be properly trained how to manage the data before and after deletion. Staffs will be having access to tools to securely delete the keys. Staff is responsible for deleting the necessary transient key when required.
A detailed policy outlining the requirements for sanitization of digital media that holds cryptocurrency keys exists and is read by all staff that has access to cryptographic keys. Procedure documents outline where sanitization is required in the processes.
An audit trail should be maintained for every sanitized media. All these audit documents identify the staff member who performed the sanitization, the specific identifiers of the media that were sanitized, which tool and configuration were used to perform the sanitization, and all other relevant information.
- PROOF OF RESERVE (POR):
This part covers the proof of control of all funds that should be held by the information system. There are known cases where systems that should be operating with a full reserve of user funds have been with a fraction of that reserve instead leading to an inability of the system to cover all withdrawals by all users. These proofs of reverse provide assurance to the public that all funds are available to the system which eliminates the risks of fund loss.
- proof of reserve audits.
An audit has been finished online that guarantees full control of all funds held by the information system. The audit has been signed by an independent party that attests to the accuracy of the audit at a time it was performed which reduces the risks associated with the inaccurate reports.
proof of reserve should be regularly conducted in an organization that provides proof that an organization continues to operate on full reserve and that all users’ funds are accessible at a time each audit is completed.
The information system is designed in such a way that an independent audit is not necessary to prove complete accessibility of user funds. The information system makes use of public ledgers such as blockchains themselves to make this information available to the public allowing anyone to conduct an audit independently.
- AUDIT LOGS
This part covers the information systems maintenance of audit logs that provide a record of all changes to information throughout the system. In the time of disaster/event or security incidents, audit logs are extremely valuable tools that can help investigators understand how the unexpected symptoms occurred and how to resolve the problems to return the information system to a consistent state. Maintain the audit logs so that it will reduces the risks associated with operational awareness and increases the information system’s ability to correct any inaccuracies.
- Application Audit Logs.
- Backup of Audit Logs.
Audit trails exist for a subset of actions that are performed within the information system. Examples of this recording audit information of all withdrawals and deposit made with the system.
All actions by all users are logged. These records will be helpful to investigations into the unexpected behavior of the information system and can help identify malicious users and responsible systems.
In addition to recording all actions performed within the system, this audit information is regularly backed up to a separate server. So that this will be helpful while investigating information in the event audit log is altered or destroyed during an attack on the information system.
These above points were some of the major key points to be noted and implemented into Organizations that deal with Crypto Currencies. Though the Crypto Industry is at the Infancy stage and still has a lot of milestones to achieve, but still there is a serious need for Crypto Companies to implement Serious Security Compliances and Policies to curb any Malicious Attacks by Hackers. The Crypto Exchanges being the prime targets of the Hackers these days, need to ensure that their Security is beefed up to not end up being a prey to such Cyber Attacks.
With this blogpost, we have made our attempt to summarize the “Crypto Currency Security Standards” which we believe is a blueprint that every Crypto Company should follow. Let us know your views on this and if we missed out any other key points that needs to be implemented for a Crypto Company, in the comment section below.