| Network Working Group | M. Sato |
| Internet-Draft | M. Shimaoka |
| Intended status: Informational | SECOM IS Lab. |
| Expires: January 26, 2019 | H. Nakajima, Ed. |
| Mercari R4D | |
| July 25, 2018 |
General Security Considerations for Crypto Assets Custodians
draft-vcgtf-crypto-assets-security-considerations-02
This document discusses technical and operational risks of crypto assets custodian and its security controls to avoid the unintended transactions for its customers.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 26, 2019.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document gives guidance as to what security measure should the crypto assets custodians consider and implement to protect the asset of its customers. The management of the secret key for the crypto assets especially has different aspects than other types of information systems and requires special attention.
This document reports especially on the appropriate management of the secret key by the crypto assets custodians to avoid the unintended transactions for its customers.
This document discusses the threat, risk, and controls on the followings:
This document is applicable to the crypto assets custodians that manages the private key that corresponds to the crypto assets. It includes the organizations that outsources the key management to another organization. In such a case, the certain recommendations applies to those outsourcers.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Terms used in this document are defined in [I-D.nakajima-crypto-asset-terminology]
In this section, a model online system of a crypto assets custodian that is used to explain the concepts and provisions in this document are explained.
Followings are the basic model of a crypto assets custodian that this document deals with.
https://raw.githubusercontent.com/VCGTF/draft-crypto-assets-security-considerations/master/CryptoAssetCustodiansSystemModeling.svg
Figure 1: Basic Model of Crypto Assets Custodian
Figure 1 Basic Model of Crypto Assets Custodian
We defined each functional element to distinguish functions logically, and do not show the actual arrangement on the actual system. For example, in our actual system, address management unit may be managed by an integrated database. Also, there are implementations with multiple functions packaged together. For example, each functional element of the transaction signature system may be integrated with the customer property management system, or the transaction signature system may be operating as another system.
When using existing implementations such as bitcoin wallet, bitcoin wallet is thought to provide the functions of transaction signature system as just one implementation as a whole. It is also conceivable that some functions are provided by a remote subcontractor as in a form in which the function of the transaction signature system is provided by an remote server.
| Types | Description |
|---|---|
| Signature Key | A private key for signing transactions (asymmetric key cryptography) |
| Verification Key | A public key for verification of transactions (asymmetric key cryptography Recipient address of transactions are unique value calculated from verification key |
| Encryption/decryption key for signature key | Secret key to keep confidentiality of signature key (symmetric key cryptography) |
| Master Seed | A seed to generate a signature key in decisional wallet |
https://raw.githubusercontent.com/VCGTF/draft-crypto-assets-security-considerations/master/SignaureKeyLifeCycle.svg
Figure 2: Lifecycle of signature key, verification key and encryption/decryption key for signature key
After a pair of a signature key and a verification key (hereafter “key pair”) is generated, an address to receive transactions is generated from the verification key. By notifying a sender of crypto assets this address, the sender is able to transfer the asset to the address. When the recipient transfers the asset to the other address, the original recipient signs the transaction data which includes the transfer order. Inactive state of the signature key is the state such that the signature key is stored in confidential manner in the signature key management function of Figure 1. An example of inactivation is encryption by encryption/decryption key (e.g. pass phrase), that is, the signature key is encrypted. In contrary, activation is the process to make the key usable to sign, by decrypting the inactivated key. The activation is assumed to be executed in transaction signing function if Figure 1. Activation and inactivation may be executed in an implementation of wallet, when the wallet have both functions. The signature key is not needed after its generation until execution of signing to transaction. Thus, there is a way to manage the signature key in offline manner with storing the verification key and address online (see Section 9.2.2).
In some crypto assets system, it is recommended not to use the same key pair twice, thus it produces multiple key pairs. This feature is for preventing trace and not relevant to the business efficiency of a crypto assets custodian. However, a crypto assets custodian should manage addresses for each customer. Thus it should manage multiple key pairs for the same crypto assets.
Suspension of key usage is only an operation inside a crypto assets custodian. By definition of blockchain based crypto assets system, any user cannot cancel transaction once it is made. As another case, it is difficult to revoke signature key even after the suspension of key. For example, a customer accidentally operate some crypto assets for suspended address. In such case, the suspended signature key is needed to make an reimbursement. Thus, suspension of keys should be conducted with considering such cases.
In this sub-clause, following items will described as characteristics of crypto assets over blockchain and distributed ledger technology in preparation for Section 8 and Section 9.
At crypto assets custodians, it is mandatory to establish, conduct, maintain and continuously improve security management. As requirements in term os security management, items described in [ISO.27001:2013] are sufficiently considered according to the business process of each crypto assets custodian. Especially, following items should be carefully considered, because a crypto assets custodian retains customer’s asset and should deal with issues specific to crypto assets.
It is needed to consider protection of customer’s assets, as well as division of responsibility with outsourcers including security of private key management for crypto asset, and mattes by which a crypto assets custodian may give social impacts like money laundering.
A crypto assets custodian should define a security policy which includes security objectives and controls described in and after clause 7. Especially, it is recommended to disclose the security policy on the management of crypto assets to customers to facilitate self evaluation.
A crypto assets custodian should watch security risks of crypto assets in addition to aligning the general security management framework, because the risks change and increase due to rapid development of related technology as described in clause 5.3.2. It is especially important to continuously evaluate risk and improve security objectives, policy and controls to keep effectiveness of security controls after starting their operations.
A crypto assets custodian should decide security objectives and controls with considering all of following viewpoints.
The crypto assets custodian conducts threat analysis, vulnerability evaluation, risk evaluation and defining security objectives and controls according to its actual business and system. Security objectives and controls should be decided with considering threats and risks specific to crypto assets described in clause 5, as well as general security objectives and controls described in [ISO.27002:2013].
Followings are items of security objectives and controls described in [ISO.27002:2013].
Consideration of above items is mandatory. Next close describes specific items to be considered by a crypto assets custodian.
The main risks to be noted as a crypto assets custodian office are roughly classified into those related to the system of the crypto assets custodian office, those caused by external factors such as a block chain outside the control of the crypto assets custodian office, and risks leading to abuse such as criminal acts Enumerate. Risks related to the system of the crypto assets custodians are organized in terms of threats and factors, actors that pose a threat. Organize in terms of possible incidents in risks caused by external factors such as block chains and risks of misuse. There may also be risks inherent in systems and operations that are different for each operator. Each business operator needs to identify the risks to be dealt with while taking into consideration the risks shown in this section, taking into consideration different systems and operations for each business operator. After that, it is desirable to determine the priority of the control measures by evaluating the impact each risk can have on the business.
Here are the typical risks to the information assets held by the system of the crypto assets custodian. In the basic model of Section 5.2, pay attention to the signing secret key and the asset data as an information asset which is particularly important from the viewpoint of protecting customer assets. If the signing secret key and the surrounding environment are not secure, it is also possible for a malicious person to create an illegal transaction and send it to the node in the block chain. Once an illegal transaction is sent to the node and written to the block chain it is nearly impossible to cancel the transaction. Therefore, prior measures to prevent illegal transactions being created are particularly important. It is necessary to carefully evaluate the risks related to management of signing secret keys and illegal transaction creation and to consider appropriate safety measures. In addition, it is necessary to consider the loss of the signing secret key. When the signing secret key is lost, it becomes impossible to use the Crypto Assets stored in the address corresponding to the signing private key. As for the risk concerning the signing secret key, consider the secret key for signature and the environment surrounding it based on the basic model in Section 5.2 in Section 8.2.1. As for the asset data, since the contents of data, data format, management form, and details of processing vary from custodians to custodians, this document considers the model more abstracted. Common contents of asset data to be protected include the total amount of Crypto Assets and legal currency deposited by the customer at the custodians, the amount of Crypto Assets and legal currency held by the custodians, customer account number and Crypto Assets An address and so on are conceivable. If such asset data is illegally rewritten by a malicious one, it will also cause damage to customers and impede the work of the custodians. The asset data is discussed in Section 8.2.2. In addition to protecting important information such as transaction signature private key and asset data, it is also necessary to consider risks such as system outage so that customers can smoothly control their own assets. Risks related to system outages are discussed in Section 8.2.3. In addition to the information and risks mentioned in this section, there are risks inherent to each system of the crypto assets custodian and risks in cooperation with external business operators. It is necessary to conduct a detailed risk assessment on the actual system of the crypto assets custodian.
In the crypto assets custodian, the role and risk of the signing key are extremely large. This is not only to enable the transfer of coins but also to disappear due to the anonymity of the Crypto Asset, the property that it is impossible to revocation the signing key against leakage / theft or roll back the transaction by. In this section, we show the risk of fraudulent use that could lead to the loss of the signing key, leakage / theft, and damage of value. It also shows supply chain risk etc. when introducing Wallet related to signature key.
Risk analysis differs depending on the assumed threats, system configuration, threat modeling, and so on. In this section, we show a case study based on the following assumption as an example. Here, the threat concerning the signature secret key and the factors that can cause the threat are assumed as follows. In addition, we assumed the following as the actor giving input to the signing secret key based on Figure 1 in Section 5.
Factors of threats are organized as follows.
Mis-operation: An act that an authorized user (including an administrator) of the system accidentally operated by mistake. For example, it is incorrectly supposed that an operation to coin 100,000 yen is incorrectly dispatched for 1 million yen.
Legitimate users’ malice: Acts performed by a legitimate user of the system (including administrator etc) with malicious intent. For example, theft or unauthorized use of the signature private key due to internal fraud. In this case, it is the purpose of identifying acts that can be factors, and the purpose and incentive of the act are not limited here.
Spoofing: An act other than an authorized user of the system impersonating a legitimate user (more accurately impersonating some kind of operation). For example, an internal burglar without administrator privilege accesses the system with administrator authority.
Intrusions from outside: an act of an outsider accessing the system maliciously in a manner other than spoofing. For example, by using malicious intrusion from the outside by exploiting the system’s vulnerability, incorporating malware into the exchanging system via targeted e-mail to the custodians administrator or the like and generating a private signature private key (or transaction creation) from the outside, Allow remote control of etc.
Unintended behaviors of implementations: The system behaves unexpectedly by the designer or operator irrespective of the intention or malice of the operation. For example, a signature private key leaks due to a bug in the exchange management system.
Of these threat factors, theft and fraudulent use are regarded as threats that can only be caused by explicit malicious factors. As a result, the possible risks for signing key to be assumed are the following:
The following sections outline each risk, and their security controls are shown in Section 9.2.2.
The disappearance risk shown in Table 8-2 is an enumeration of events having a possibility of causing disappearance, paying attention to the input (operation instruction) to the signature secret key. As a typical risk, loss of the secret key for signature due to erroneous operation by the administrator may be considered.
Intentional operation by malicious intention is essential, but leakage can be caused by negligence without malice. For this reason, leakage risk and theft risk need to be sorted out.
The leakage risk shown in Table 8-2 lists events that have the possibility of causing leakage including negligence, paying attention to the input (operation instruction) to the signing secret key. Typically, an internal criminal, leakage risk due to unintentional behavior, illegal invasion, etc. can be considered. Likewise, the theft risk enumerates events that have the possibility of being woken up by some sort of malicious intention, paying attention to the input (operation instruction) to the signature secret key. Typically, there is a risk of leakage from internal criminals or unauthorized intrusion from the outside.
Both leaks and theft are similar in terms of leakage of sensitive information to the outside, and the control measures are common. This will be described later in Section 9.3.2.
The fraudulent use risk shown in Table 8-2 is an enumeration of events having a possibility of being caused by something with a malicious intention, paying attention to the input (operation instruction) to the signature secret key. Typically, there is a risk of illegal use due to illegal invasion or impersonation from the outside.
Supply chain risk of hardware wallet As a product having a secret key management function, there is a so-called hardware wallet. Many hardware wallets connect to the management terminal such as PC via USB and perform key management operation from the management terminal. FIPS 140-2, etc. as a security certification of products with key management function, etc. However, since most of cryptographic algorithms handled by Crypto Assets are not subject to certification, the security of hardware wallet for Crypto Assets Unfortunately it is inevitable that the third-party accreditation system on insurance is inadequate. For this reason, while there are products with sufficient safety in the hardware wallet that generally available, it is necessary to recognize that there are products with insufficient safety. Furthermore, even with products with certain safety, safety may be impaired by being crafted on the distribution route. For example, a hardware wallet that is loaded with malware in the middle of a sales channel, even if the purchaser newly generates a signing secret key in the hardware wallet, the attacker can use the signature secret It becomes possible to restore the key.
The asset data is data for managing assets such as Crypto Assets and statutory currency held by customers and custodians. The secret key of the transaction signature shall not be included (see Section 5.2). As mentioned above, since asset data varies from custodians to custodians, we consider this as a more abstracted model in this document. Since detailed threat analysis and risk assessment need to be performed on the asset data handled by the actual custodian system, only the way of thinking is shown here. The main threats of asset data may be illegal rewriting, loss, or leakage. The factors include mis-operation by the manager, malice of the righteous person, spoofing the legitimate person, malicious intent of the outsider, unintended behavior of the system. In the example of the basic model in Section 5.2, there is a route from the exchange management system, the customer property management system, and the incoming coin determination unit. Among the threats of asset data, the following examples are considered as incidents due to illegal rewriting. A customer asset management system referring to unauthorized asset data may create an illegal transaction and flow through the normal process to the block chain (Section 8.2.1.4). For example, it is possible to rewrite the holding amount recorded in the asset data, change the Crypto Assets transfer destination address, or the like. For example, by rewriting the list of addresses associated with the customer, illegal recombination of the amount held between customers or between customers and custodians within the asset data within the custodian will be made. As a transaction in the block chain the result is not reflected, assets that a customer or custodian should have had is lost. Risks related to asset data can be thought of as a problem similar to general financial and settlement systems, but transactions can be canceled if transactions are written to the block chain as a result of fraud against asset data It is necessary to consider it on the premise that there is no property.
The system of the crypto assets custodian office is software, hardware, network, and the like constituting the crypto assets custodian. In addition, the term “operation” refers to an operation performed manually, such as operation monitoring of a switching center system, account opening, remittance instruction, wallet deposit / withdrawal. It is conceivable that the system and work may be stopped due to various factors. Risks related to suspension of systems and operations can be regarded as problems similar to general financial and payment systems. However, the fact that the crypto assets custodian office is connected to the Internet all the time, not the dedicated communication network at all times, that it is operating 24 hours a day, 365 days, that many crypto assets custodians are built on the public cloud infrastructure, crypto assets custodian It is necessary to consider it based on the fact that the operating situation of the place has a large effect on the crypto assets price and it tends to be an object of attack.
Crypto assets custodians frequently receive denial of service attacks. As a target of a denial-of-service attack, publicly-released top page, API endpoint, etc. are common, but when an attacker knows the system configuration and a business system or operation monitoring system is placed on the Internet, A case of receiving a denial of service attack may be considered.
It is conceivable that the data center, the cloud infrastructure, etc. where the system is installed are stopped, and the system and operations are stopped. The system can be stopped due to various factors such as power outage due to natural disasters and disruption of communication, large scale failure due to mistake by cloud infrastructure operator, large scale system failure due to mistake of infrastructure operation, failure of software release.
Even if the system itself is in operation, if operations monitoring and tasks of personnel responsible for the operation are hindered, the work will be suspended. For example, regular inspections of power facilities at operation bases, disruption of transportation means due to catastrophic changes and strikes, protest activities and rush of press reporters may hinder the entrance and exit of buildings and halt operations. In addition, when personnel are using the same transportation method or participating in the same event, there is a risk that many personnel can not operate due to the same accident such as traffic accident or food poisoning.
In countries where the crypto assets custodian office is stipulated, licensing system or registration system, business may be suspended due to business improvement order, business suspension order, deletion of registration etc etc.
Even if the systems and operations of the crypto assets custodian are appropriately operated, if the blockchain / network in which the crypto assets operates and the Internet infrastructure supporting the connection between the nodes are attacked, On the other hand, the service cannot be continued or the transaction can not be handled properly.
An attacker interferes with routing of the Internet such as route hijacking and domain name resolution (Domain Name Service), hindering the reachability to the custodians and guiding it to a fake custodian office or block chain It is possible to intentionally cause a branch by hindering synchronization. This method can be considered not only by malicious attackers but also by ISP etc. based on instructions from the government.
Many crypto assets custodian offices provide services on the Web, and TLS and server certificates are used for user authenticity verification and encryption of sites. When a certificate authority issuing a server certificate is attacked, it may be possible to impersonate the site, or if the server certificate is revoked, the service cannot be provided.
By intervening with an e-mail or other messaging system, an attacker can fraud and block SMS / MMS of e-mails and mobile phones used for interaction with users and delivery of one-time passwords. When a user’s message is fraudulent, it is possible to log in as a user and reset the password.
By misusing a bug in the agreement algorithm, fake transaction information is sent to a specific node and disguised as to whether or not to send money to the counter party. For example, in the case of the MtGOX case in 2014, double payment attacks abusing Transaction Malleability occurred frequently in piggybacking.
As a part of AML / CFT, there are cases where banks refuse to open accounts related to the work of the crypto assets custodian office, the risk that the bank accounts will be frozen, such as receiving guidance from the regulatory authorities or accident is there. In the event that the account is frozen, the business of depositing and withdrawing a legal currency with the user as a crypto assets custodian office is stopped.
As a part of AML/CFT, when another crypto assets custodian trader remittles to another crypto assets address, there are cases where it is checked whether the remittance destination address does not correspond to a high risk transaction. In the case where the address of the hot wallet of the custodian office is registered as a problematic address, it is assumed that the custodian of the crypto assets with such a service can not be performed smoothly. Since it is common in many cases that criminal remit crypto assets stolen for disturbance to a known address, there is a risk that the address of the hot wallet of the crypto assets custodian office will be classified as a high risk customer by mistake.
There is a risk that the URL of the crypto assets custodian office is filtered by the network or blocked by the ISP so that the user can not access it. Also, if it is recognized as a malware distribution site or the like, there is a risk that it will not be displayed as a search result or it will be impossible to browse from the browser.
As a measure against spam mails, most of mail servers provide mail rejection based on reputation and classification function of spam mails. If the e-mail delivered by the custodian is judged as spam, it may be impossible to contact the user.
Depending on the platform, there are cases where handling of crypto assets by the application is restricted. If the examination of the smartphone application is dropped, the user may not be able to download the smartphone application for accessing the custodian and may be unable to use the service.
In this clause, considerations from the ISMS viewpoint in implementing security controls to crypto assets custodians for risks described in clause 8 are described. They included issues caused by specific characteristics to crypto assets. This clause also describes relationship to [ISO.27001:2013] and [ISO.27002:2013] for each consideration.
### Direction of the information security management
Objectives of security management at a crypto assets custodian contain secure protection of customer’s asset, compliance to business requirements, laws and rules, and realization of social responsibility. Security policies and execution statements derived from such objectives are recommended to be publicly available for consumers, business partners, auditor and regulators to help their judge.
In general, followings are required in management of private cryptographic keys.
Followings are three basic security control to realize above. Additional security controls specific to crypto assets custodians are described in and after sub-clause Section 9.2.2.
Backup is the most fundamental and effective measure against lost of signing key. On the other hand, there are risks of leakage and lost of backup device. These risks depend on the kind backup device, thus security controls on such devices should be considered independently. Followings describe typical backup devices and leakage/theft risks associated with them.
If a signing key is managed by a tamper-resistant key management device (device X) and X has cloning function, cloning the key to another device Y is the most secure way to backup the key, where the cloning function is the technique to copy the key with keeping confidentiality to other devices than X and Y. The implementation of the function is recommended to be evaluated/certified by certification program like CMVP or FIPS 140. Note that, the cryptographic algorithms supported by such tamper-resistant key management devices are limited and all crypto assets systems can utilize it, but it is one of the most secure way of backup.
Here, it is assumed to backup keys to storage like USB memory and DVD. There are two types of operations; one is backup data is stored in movable devices in offline manner, the other is backup data is stored in online accessible manner. If the device is movable, the possibility of steal and lost increases, thus the device should be kept in a cabinet or a vault with key, and the access control to such cabinet/vault should be restrict.
Of the backup storage is online, risks of leakage and theft should be assumed as same as the key management function implementation inside the crypto assets custodian. In general, the same security control is recommended to such backup storage. If there is some additional operation, for example the backup device is inactivated except for the time of restore, the security control may be modified with considering operation environment. When it is not avoided the raw key data is be outside of the key management function implementation, the custodian should deal with the problem of remained magnetics.
There is a way to backup keys in offline manner, to print them to papers as a QR code or other machine readable ways. It is movable than storage for digital data and easy to identify. There remains some risk of leakage and theft by taking a photo by smartphone and so on.
There is a type of offline key management (as known as “cold wallet”) which isolates private keys from the system network to prevent leakage and theft caused by intrusion.
In this case, some offline operation is needed to make the system use the key. Examples are, keys are usually stored inside a vault and connected to the system only when it is utilized, and USB memory is used to data transportation between an online system and an offline system. If there is not explicit approval process in the offline operation for key usage, anyone cannot stop malicious transaction. That is, this solution can prevent lost and theft, however, an explicit approval process is needed to prevent abuse of keys.
It is also a good security control to distribute the right to use private key to multiple entity. There are two examples; division of secret key and multi-signature.
In this sub-clause, following topics will be described.
Following security controls addition to kay management in sub clause Section 9.2.2 will be described in this sub clause.
Above controls are described with aligning to [ISO.27002:2013] and considering security controls specific to crypto assets custodians. The structure of this sub clause aligns the structure of [ISO.27002:2013].
Security Considerations are included in main section of this document.
None.
| [ISO.27001:2013] | International Organization for Standardization, "Information technology -- Security techniques -- Information security management systems -- Requirements", ISO/IEC 27001:2013, October 2013. |
| [ISO.27002:2013] | International Organization for Standardization, "Information technology -- Security techniques -- Code of practice for information security controls", ISO/IEC 27002:2013, October 2013. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
| [I-D.nakajima-crypto-asset-terminology] | Nakajima, H., Kusunoki, M., Hida, K., Suga, Y. and T. Hayashi, "Terminology for Crypto Asset", Internet-Draft draft-nakajima-crypto-asset-terminology-00, July 2018. |
Thanks to Masanori Kusunoki, Yasushi Matsumoto, Natsuhiko Sakimura, Yuji Suga, Tatsuya Hayashi, Keiichi Hida and other members of the Security Working Group of Virtual Currency Governance Task Force.