idnits 2.17.1 draft-vcgtf-crypto-assets-security-considerations-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 58 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 25, 2018) is 2101 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-nakajima-crypto-asset-terminology-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Sato 3 Internet-Draft M. Shimaoka 4 Intended status: Informational SECOM IS Lab. 5 Expires: January 26, 2019 H. Nakajima, Ed. 6 Mercari R4D 7 July 25, 2018 9 General Security Considerations for Crypto Assets Custodians 10 draft-vcgtf-crypto-assets-security-considerations-02 12 Abstract 14 This document discusses technical and operational risks of crypto 15 assets custodian and its security controls to avoid the unintended 16 transactions for its customers. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 26, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Scope of this document . . . . . . . . . . . . . . . . . . . 3 54 3. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 55 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Basic description of a model online system of a crypto assets 57 custodian . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5.2. A basic model of online system of a crypto assets 60 custodian and its functional components . . . . . . . . . 4 61 5.3. The flow leading to the sending of the transaction . . . 6 62 5.4. Types of keys that are used for signature and encryption 6 63 5.4.1. Type of keys . . . . . . . . . . . . . . . . . . . . 6 64 5.4.2. Flow for the key generation and the key usage . . . . 7 65 5.4.3. On the usage of multiple keys . . . . . . . . . . . . 8 66 5.4.4. On the suspension of keys . . . . . . . . . . . . . . 8 67 5.5. On the characteristics of crypto assets on Blockchain and 68 distributed ledger technologies . . . . . . . . . . . . . 8 69 5.5.1. The importance of the private key used for signing . 8 70 5.5.2. Diversity of implementations . . . . . . . . . . . . 8 71 5.5.3. On the possibility of the forking of the Blockchain . 8 72 5.5.4. Risk on the unapproved transactions . . . . . . . . . 8 73 6. Basic objectives for the security management of crypto assets 74 custodians . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7. Approaches to basic security controls . . . . . . . . . . . . 9 76 8. Risks of Crypto Assets Custodian . . . . . . . . . . . . . . 11 77 8.1. About this section . . . . . . . . . . . . . . . . . . . 11 78 8.2. Risks related to the system of the crypto assets 79 custodian . . . . . . . . . . . . . . . . . . . . . . . . 11 80 8.2.1. Risks related to signing keys . . . . . . . . . . . . 12 81 8.2.2. Risks related to asset data . . . . . . . . . . . . . 18 82 8.2.3. Risks related to suspension of systems and operations 18 83 8.3. Risks from external factors . . . . . . . . . . . . . . . 20 84 8.3.1. Risks related to the Internet infrastructure and 85 authentication infrastructure . . . . . . . . . . . . 20 86 8.3.2. Troubles due to block chains of crypto assets . . . . 20 87 8.3.3. Risks arising from external reputation databases . . 21 88 8.4. Financial Crime Risks . . . . . . . . . . . . . . . . . . 22 89 8.4.1. Risk of being abused in criminal acts . . . . . . . . 22 90 8.4.2. Anti Money Laundering . . . . . . . . . . . . . . . . 22 91 8.4.3. Counter Financing of Terrorism . . . . . . . . . . . 22 92 9. Consideration on security controls at crypto assets custodian 22 93 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 22 94 9.2. Consideration on security controls . . . . . . . . . . . 22 95 9.2.1. Security controls on signing keys . . . . . . . . . . 23 96 9.2.2. Security controls at crypto assets custodian . . . . 26 97 9.3. Countermeasures against risks caused by blockchain and 98 network environment . . . . . . . . . . . . . . . . . . . 27 99 9.4. Risk mitigation against crimes . . . . . . . . . . . . . 27 100 10. Remaining issues . . . . . . . . . . . . . . . . . . . . . . 27 101 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 102 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 104 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 105 13.2. Informative References . . . . . . . . . . . . . . . . . 27 106 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 109 1. Introduction 111 This document gives guidance as to what security measure should the 112 crypto assets custodians consider and implement to protect the asset 113 of its customers. The management of the secret key for the crypto 114 assets especially has different aspects than other types of 115 information systems and requires special attention. 117 This document reports especially on the appropriate management of the 118 secret key by the crypto assets custodians to avoid the unintended 119 transactions for its customers. 121 2. Scope of this document 123 This document discusses the threat, risk, and controls on the 124 followings: 126 o Online system of crypto assets custodian that provides the 127 custodian service to its customer (consumers and trade partners); 129 o Assets information (including the private key of the crypto 130 assets) that the online system of a crypto assets custodian 131 manages; 133 o Social impact that can arise from the discrepancy in the security 134 measures that are implemented in the online system of a crypto 135 assets custodian. 137 This document is applicable to the crypto assets custodians that 138 manages the private key that corresponds to the crypto assets. It 139 includes the organizations that outsources the key management to 140 another organization. In such a case, the certain recommendations 141 applies to those outsourcers. 143 3. Conventions and Definitions 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 4. Terminology 153 Terms used in this document are defined in 154 [I-D.nakajima-crypto-asset-terminology] 156 5. Basic description of a model online system of a crypto assets 157 custodian 159 5.1. General 161 In this section, a model online system of a crypto assets custodian 162 that is used to explain the concepts and provisions in this document 163 are explained. 165 5.2. A basic model of online system of a crypto assets custodian and 166 its functional components 168 Followings are the basic model of a crypto assets custodian that this 169 document deals with. 171 https://raw.githubusercontent.com/VCGTF/draft-crypto-assets-security-considerations/master/CryptoAssetCustodiansSystemModeling.svg 173 Figure 1: Basic Model of Crypto Assets Custodian 175 Figure 1 Basic Model of Crypto Assets Custodian 177 o Customer Interface 178 Provides screen and input functions such as login process, account 179 management (deposit/withdrawal instruction etc.) and trade 180 instruction for the customers(users). Web application, API, etc. 182 o Customer Authentication Function 183 Performs user authentication process for login to the crypto 184 assets custodians. 186 o Customer Credential Database 187 Manages required IDs for login and verification information 188 related to user authentication process (f.g password verification 189 info.). 191 o Customer Assets Management Function 192 A group of functions to manage customer accounts. Receive 193 instructions for deposit or withdrawal (outgoing coins) and 194 perform processing according to the user instructions. Refer or 195 update asset data. 197 o Blockchain Node 198 Connects to another blockchain nodes to retrieve blockchain data. 200 o Incoming transaction management Function 201 Checks transaction stored in blockchain and confirm whether 202 incoming coins are involved in the specified addresses. 204 o Order processing function 205 A group of functions that receives sales instructions from 206 customers and performs processing related to trading of crypto 207 assets. Refers and updates asset data based on asset data. 209 o Assets Database 210 Manages holdings of fiat currencies and crypto assets. It does 211 not include the private keys for signing transactions. Managed 212 separately from the assets of the custodian for each customer. 214 o Transaction Singing Function 216 * Transaction Generator 217 Generates transactions to be sent to the blockchain based on 218 instructions from the customer asset management system or the 219 exchange management system. 221 * Transaction Broadcaster 222 Sends the signed transaction to the blockchain. Connects to 223 nodes of the another nodes on the blockchain. 225 * Transaction Signing Function 226 Generates digital signatures based on the instructed 227 transaction contents and the private signature key (with IDs 228 and addresses). 230 * Address Management 231 Manages public keys with related to the private signature keys, 232 or addresses (such as values calculated from the public keys). 234 * Private Signature Key Management Function 235 Manages the signing keys of the crypto assets (the keys used 236 for the transaction signing). Sometimes it is separated into 237 the cold-wallet as security sountermeasure. "Signature key 238 generator" creates signature keys. The generated keys are 239 registered in the signature key management unit, and the public 240 keys and addresses are registered in the address management 241 units. 243 o Exchange Operation Modules 244 A group of functions for custodians' administrators. Based on 245 operations from administrators, instructs generation of generating 246 new signature keys or transfer crypto assets. 248 o Operator Authentication Function 249 Authenticates the administrator users. 251 o Operator Audit Database 252 Manages verification data related to the authentication processes 253 of the administrators. 255 We defined each functional element to distinguish functions 256 logically, and do not show the actual arrangement on the actual 257 system. For example, in our actual system, address management unit 258 may be managed by an integrated database. Also, there are 259 implementations with multiple functions packaged together. For 260 example, each functional element of the transaction signature system 261 may be integrated with the customer property management system, or 262 the transaction signature system may be operating as another system. 264 When using existing implementations such as bitcoin wallet, bitcoin 265 wallet is thought to provide the functions of transaction signature 266 system as just one implementation as a whole. It is also conceivable 267 that some functions are provided by a remote subcontractor as in a 268 form in which the function of the transaction signature system is 269 provided by an remote server. 271 5.3. The flow leading to the sending of the transaction 273 5.4. Types of keys that are used for signature and encryption 275 5.4.1. Type of keys 276 +-----------------------+-------------------------------------------+ 277 | Types | Description | 278 +-----------------------+-------------------------------------------+ 279 | Signature Key | A private key for signing transactions | 280 | | (asymmetric key cryptography) | 281 | | | 282 | Verification Key | A public key for verification of | 283 | | transactions (asymmetric key cryptography | 284 | | Recipient address of transactions are | 285 | | unique value calculated from verification | 286 | | key | 287 | | | 288 | Encryption/decryption | Secret key to keep confidentiality of | 289 | key for signature key | signature key (symmetric key | 290 | | cryptography) | 291 | | | 292 | Master Seed | A seed to generate a signature key in | 293 | | decisional wallet | 294 +-----------------------+-------------------------------------------+ 296 5.4.2. Flow for the key generation and the key usage 298 https://raw.githubusercontent.com/VCGTF/draft-crypto-assets-security-considerations/master/SignaureKeyLifeCycle.svg 300 Figure 2: Lifecycle of signature key, verification key and 301 encryption/decryption key for signature key 303 After a pair of a signature key and a verification key (hereafter 304 "key pair") is generated, an address to receive transactions is 305 generated from the verification key. By notifying a sender of crypto 306 assets this address, the sender is able to transfer the asset to the 307 address. When the recipient transfers the asset to the other 308 address, the original recipient signs the transaction data which 309 includes the transfer order. Inactive state of the signature key is 310 the state such that the signature key is stored in confidential 311 manner in the signature key management function of Figure 1. An 312 example of inactivation is encryption by encryption/decryption key 313 (e.g. pass phrase), that is, the signature key is encrypted. In 314 contrary, activation is the process to make the key usable to sign, 315 by decrypting the inactivated key. The activation is assumed to be 316 executed in transaction signing function if Figure 1. Activation and 317 inactivation may be executed in an implementation of wallet, when the 318 wallet have both functions. The signature key is not needed after 319 its generation until execution of signing to transaction. Thus, 320 there is a way to manage the signature key in offline manner with 321 storing the verification key and address online (see Section 9.2.2). 323 5.4.3. On the usage of multiple keys 325 In some crypto assets system, it is recommended not to use the same 326 key pair twice, thus it produces multiple key pairs. This feature is 327 for preventing trace and not relevant to the business efficiency of a 328 crypto assets custodian. However, a crypto assets custodian should 329 manage addresses for each customer. Thus it should manage multiple 330 key pairs for the same crypto assets. 332 5.4.4. On the suspension of keys 334 Suspension of key usage is only an operation inside a crypto assets 335 custodian. By definition of blockchain based crypto assets system, 336 any user cannot cancel transaction once it is made. As another case, 337 it is difficult to revoke signature key even after the suspension of 338 key. For example, a customer accidentally operate some crypto assets 339 for suspended address. In such case, the suspended signature key is 340 needed to make an reimbursement. Thus, suspension of keys should be 341 conducted with considering such cases. 343 5.5. On the characteristics of crypto assets on Blockchain and 344 distributed ledger technologies 346 In this sub-clause, following items will described as characteristics 347 of crypto assets over blockchain and distributed ledger technology in 348 preparation for Section 8 and Section 9. 350 5.5.1. The importance of the private key used for signing 352 5.5.2. Diversity of implementations 354 5.5.2.1. On the cryptographic algorithms used by crypto assets 356 5.5.3. On the possibility of the forking of the Blockchain 358 5.5.3.1. Rollback by reorganization 360 5.5.3.2. The treatment of the forked crypto assets 362 5.5.4. Risk on the unapproved transactions 364 5.5.4.1. General 366 5.5.4.2. The handling of the unapproved transactions 367 5.5.4.3. Transaction failures caused by the vulnerabilities of the 368 implementation or the specification of the crypto assets 370 6. Basic objectives for the security management of crypto assets 371 custodians 373 At crypto assets custodians, it is mandatory to establish, conduct, 374 maintain and continuously improve security management. As 375 requirements in term os security management, items described in 376 [ISO.27001:2013] are sufficiently considered according to the 377 business process of each crypto assets custodian. Especially, 378 following items should be carefully considered, because a crypto 379 assets custodian retains customer's asset and should deal with issues 380 specific to crypto assets. 382 o On stakeholders (Related to [ISO.27001:2013] Clause 4) 384 It is needed to consider protection of customer's assets, as well as 385 division of responsibility with outsourcers including security of 386 private key management for crypto asset, and mattes by which a crypto 387 assets custodian may give social impacts like money laundering. 389 o On security policy (Related to [ISO.27001:2013] Clause 5) 391 A crypto assets custodian should define a security policy which 392 includes security objectives and controls described in and after 393 clause 7. Especially, it is recommended to disclose the security 394 policy on the management of crypto assets to customers to facilitate 395 self evaluation. 397 o Continuous risk evaluation and improvement (Related to 398 [ISO.27002:2013] Clause 6, 8, 9 and 10) 400 A crypto assets custodian should watch security risks of crypto 401 assets in addition to aligning the general security management 402 framework, because the risks change and increase due to rapid 403 development of related technology as described in clause 5.3.2. It 404 is especially important to continuously evaluate risk and improve 405 security objectives, policy and controls to keep effectiveness of 406 security controls after starting their operations. 408 7. Approaches to basic security controls 410 A crypto assets custodian should decide security objectives and 411 controls with considering all of following viewpoints. 413 o Countermeasure to threat as lost, theft, leak and abuse of 414 customer's assets data and private key for crypto assets 416 o Requirements for actual business 418 o Compliance to laws and rules 420 o Social responsibilities to prevent crimes in use of crypto assets 421 like scam and money laundering 423 The crypto assets custodian conducts threat analysis, vulnerability 424 evaluation, risk evaluation and defining security objectives and 425 controls according to its actual business and system. Security 426 objectives and controls should be decided with considering threats 427 and risks specific to crypto assets described in clause 5, as well as 428 general security objectives and controls described in 429 [ISO.27002:2013]. 431 Followings are items of security objectives and controls described in 432 [ISO.27002:2013]. 434 o Information Security Policies 436 o Organization of information security 438 o Human resource security 440 o Assets management 442 o Access control 444 o Cryptography 446 o Physical and environmental security 448 o Operations security 450 o Communications security 452 o System acquisition, development and maintenance 454 o Supplier relationships 456 o Information security incident management 458 o Information security aspects of business continuity management 460 o Compliance 462 Consideration of above items is mandatory. Next close describes 463 specific items to be considered by a crypto assets custodian. 465 8. Risks of Crypto Assets Custodian 467 8.1. About this section 469 The main risks to be noted as a crypto assets custodian office are 470 roughly classified into those related to the system of the crypto 471 assets custodian office, those caused by external factors such as a 472 block chain outside the control of the crypto assets custodian 473 office, and risks leading to abuse such as criminal acts Enumerate. 474 Risks related to the system of the crypto assets custodians are 475 organized in terms of threats and factors, actors that pose a threat. 476 Organize in terms of possible incidents in risks caused by external 477 factors such as block chains and risks of misuse. There may also be 478 risks inherent in systems and operations that are different for each 479 operator. Each business operator needs to identify the risks to be 480 dealt with while taking into consideration the risks shown in this 481 section, taking into consideration different systems and operations 482 for each business operator. After that, it is desirable to determine 483 the priority of the control measures by evaluating the impact each 484 risk can have on the business. 486 8.2. Risks related to the system of the crypto assets custodian 488 Here are the typical risks to the information assets held by the 489 system of the crypto assets custodian. In the basic model of 490 Section 5.2, pay attention to the signing secret key and the asset 491 data as an information asset which is particularly important from the 492 viewpoint of protecting customer assets. If the signing secret key 493 and the surrounding environment are not secure, it is also possible 494 for a malicious person to create an illegal transaction and send it 495 to the node in the block chain. Once an illegal transaction is sent 496 to the node and written to the block chain it is nearly impossible to 497 cancel the transaction. Therefore, prior measures to prevent illegal 498 transactions being created are particularly important. It is 499 necessary to carefully evaluate the risks related to management of 500 signing secret keys and illegal transaction creation and to consider 501 appropriate safety measures. In addition, it is necessary to 502 consider the loss of the signing secret key. When the signing secret 503 key is lost, it becomes impossible to use the Crypto Assets stored in 504 the address corresponding to the signing private key. As for the 505 risk concerning the signing secret key, consider the secret key for 506 signature and the environment surrounding it based on the basic model 507 in Section 5.2 in Section 8.2.1. As for the asset data, since the 508 contents of data, data format, management form, and details of 509 processing vary from custodians to custodians, this document 510 considers the model more abstracted. Common contents of asset data 511 to be protected include the total amount of Crypto Assets and legal 512 currency deposited by the customer at the custodians, the amount of 513 Crypto Assets and legal currency held by the custodians, customer 514 account number and Crypto Assets An address and so on are 515 conceivable. If such asset data is illegally rewritten by a 516 malicious one, it will also cause damage to customers and impede the 517 work of the custodians. The asset data is discussed in 518 Section 8.2.2. In addition to protecting important information such 519 as transaction signature private key and asset data, it is also 520 necessary to consider risks such as system outage so that customers 521 can smoothly control their own assets. Risks related to system 522 outages are discussed in Section 8.2.3. In addition to the 523 information and risks mentioned in this section, there are risks 524 inherent to each system of the crypto assets custodian and risks in 525 cooperation with external business operators. It is necessary to 526 conduct a detailed risk assessment on the actual system of the crypto 527 assets custodian. 529 8.2.1. Risks related to signing keys 531 In the crypto assets custodian, the role and risk of the signing key 532 are extremely large. This is not only to enable the transfer of 533 coins but also to disappear due to the anonymity of the Crypto Asset, 534 the property that it is impossible to revocation the signing key 535 against leakage / theft or roll back the transaction by. In this 536 section, we show the risk of fraudulent use that could lead to the 537 loss of the signing key, leakage / theft, and damage of value. It 538 also shows supply chain risk etc. when introducing Wallet related to 539 signature key. 541 8.2.1.1. Risk analysis of signing secret key 543 Risk analysis differs depending on the assumed threats, system 544 configuration, threat modeling, and so on. In this section, we show 545 a case study based on the following assumption as an example. Here, 546 the threat concerning the signature secret key and the factors that 547 can cause the threat are assumed as follows. In addition, we assumed 548 the following as the actor giving input to the signing secret key 549 based on Figure 1 in Section 5. 551 o Threats: 553 * lost 555 * leakage, theft 557 * fraudulent use 559 o Factors of Threats: 561 * mis-operations 563 * Legitimate users' malice 565 * Spoofing 567 * Intrusions from outside 569 * Unintended behaviors of implementations 571 o Actors: 573 * exchange operation modules 575 * Transaction Signing modules 577 * customer asset management function implementation 579 * incoming coin management function implementation 581 Factors of threats are organized as follows. 583 Mis-operation: An act that an authorized user (including an 584 administrator) of the system accidentally operated by mistake. For 585 example, it is incorrectly supposed that an operation to coin 100,000 586 yen is incorrectly dispatched for 1 million yen. 588 Legitimate users' malice: Acts performed by a legitimate user of the 589 system (including administrator etc) with malicious intent. For 590 example, theft or unauthorized use of the signature private key due 591 to internal fraud. In this case, it is the purpose of identifying 592 acts that can be factors, and the purpose and incentive of the act 593 are not limited here. 595 Spoofing: An act other than an authorized user of the system 596 impersonating a legitimate user (more accurately impersonating some 597 kind of operation). For example, an internal burglar without 598 administrator privilege accesses the system with administrator 599 authority. 601 Intrusions from outside: an act of an outsider accessing the system 602 maliciously in a manner other than spoofing. For example, by using 603 malicious intrusion from the outside by exploiting the system's 604 vulnerability, incorporating malware into the exchanging system via 605 targeted e-mail to the custodians administrator or the like and 606 generating a private signature private key (or transaction creation) 607 from the outside, Allow remote control of etc. 609 Unintended behaviors of implementations: The system behaves 610 unexpectedly by the designer or operator irrespective of the 611 intention or malice of the operation. For example, a signature 612 private key leaks due to a bug in the exchange management system. 614 Of these threat factors, theft and fraudulent use are regarded as 615 threats that can only be caused by explicit malicious factors. As a 616 result, the possible risks for signing key to be assumed are the 617 following: 619 1. Threat by lost - Risk of Unauthorized operation (with legitimate 620 path) 622 * End-user's malice 624 * Operator's malice in Custodian 626 * Spoofing to end users 628 * internal frauds (spoofing to operators) - Risk of Intrusion 629 from the outside 631 * Intrusion into the transaction signing modules 633 * Intrusion into the incoming coin management function 634 (implementation) 636 * Intrusion into the customer asset management function 637 (implementation) 639 * Intrusion into the exchange operation modules - Risk of System 640 Behaviors different from human operation 642 * Unintended behaviors of the transaction signing modules 644 * Unintended behaviors of the incoming coin management function 645 (implementation) 647 * Unintended behaviors of the customer asset management function 648 (implementation) 650 * Unintended behaviors of the exchange operation modules - Risk 651 of mis-operation (by human error) 653 * Mis-operation of end user 655 * Mis-operation of operator 657 2. Threat by leakage - Risk of Unauthorized operation (with 658 legitimate path) 660 * End-user's malice 662 * Operator's malice in Custodian 664 * Spoofing to end users 666 * internal frauds (spoofing to operators) - Risk of Intrusion 667 from the outside 669 * Intrusion into the transaction signing modules 671 * Intrusion into the incoming coin management function 672 (implementation) 674 * Intrusion into the customer asset management function 675 (implementation) 677 * Intrusion into the exchange operation modules - Risk of System 678 Behaviors different from human operation 680 * Unintended behaviors of the transaction signing modules 682 * Unintended behaviors of the incoming coin management function 683 (implementation) 685 * Unintended behaviors of the customer asset management function 686 (implementation) 688 * Unintended behaviors of the exchange operation modules - Risk 689 of mis-operation (by human error) 691 * Mis-operation of end user 693 * Mis-operation of operator 695 3. Threat by theft - Risk of Unauthorized operation (with legitimate 696 path) 698 * End-user's malice 700 * Operator's malice in Custodian 702 * Spoofing to end users 703 * internal frauds (spoofing to operators) - Risk of Intrusion 704 from the outside 706 * Intrusion into the transaction signing modules 708 * Intrusion into the incoming coin management function 709 (implementation) 711 * Intrusion into the customer asset management function 712 (implementation) 714 * Intrusion into the exchange operation modules 716 4. Threat by fraudulent use - Risk of Unauthorized operation (with 717 legitimate path) 719 * End-user's malice 721 * Operator's malice in Custodian 723 * Spoofing to end users 725 * internal frauds (spoofing to operators) - Risk of Intrusion 726 from the outside 728 * Intrusion into the transaction signing modules 730 * Intrusion into the incoming coin management function 731 (implementation) 733 * Intrusion into the customer asset management function 734 (implementation) 736 * Intrusion into the exchange operation modules 738 The following sections outline each risk, and their security controls 739 are shown in Section 9.2.2. 741 8.2.1.2. Risk of loss of signing secret key 743 The disappearance risk shown in Table 8-2 is an enumeration of events 744 having a possibility of causing disappearance, paying attention to 745 the input (operation instruction) to the signature secret key. As a 746 typical risk, loss of the secret key for signature due to erroneous 747 operation by the administrator may be considered. 749 8.2.1.3. Leakage / theft risk of signing private key 751 Intentional operation by malicious intention is essential, but 752 leakage can be caused by negligence without malice. For this reason, 753 leakage risk and theft risk need to be sorted out. 755 The leakage risk shown in Table 8-2 lists events that have the 756 possibility of causing leakage including negligence, paying attention 757 to the input (operation instruction) to the signing secret key. 758 Typically, an internal criminal, leakage risk due to unintentional 759 behavior, illegal invasion, etc. can be considered. Likewise, the 760 theft risk enumerates events that have the possibility of being woken 761 up by some sort of malicious intention, paying attention to the input 762 (operation instruction) to the signature secret key. Typically, 763 there is a risk of leakage from internal criminals or unauthorized 764 intrusion from the outside. 766 Both leaks and theft are similar in terms of leakage of sensitive 767 information to the outside, and the control measures are common. 768 This will be described later in Section 9.3.2. 770 8.2.1.4. Risk of unauthorized use of signing private key 772 The fraudulent use risk shown in Table 8-2 is an enumeration of 773 events having a possibility of being caused by something with a 774 malicious intention, paying attention to the input (operation 775 instruction) to the signature secret key. Typically, there is a risk 776 of illegal use due to illegal invasion or impersonation from the 777 outside. 779 8.2.1.5. Other related risks 781 Supply chain risk of hardware wallet As a product having a secret key 782 management function, there is a so-called hardware wallet. Many 783 hardware wallets connect to the management terminal such as PC via 784 USB and perform key management operation from the management 785 terminal. FIPS 140-2, etc. as a security certification of products 786 with key management function, etc. However, since most of 787 cryptographic algorithms handled by Crypto Assets are not subject to 788 certification, the security of hardware wallet for Crypto Assets 789 Unfortunately it is inevitable that the third-party accreditation 790 system on insurance is inadequate. For this reason, while there are 791 products with sufficient safety in the hardware wallet that generally 792 available, it is necessary to recognize that there are products with 793 insufficient safety. Furthermore, even with products with certain 794 safety, safety may be impaired by being crafted on the distribution 795 route. For example, a hardware wallet that is loaded with malware in 796 the middle of a sales channel, even if the purchaser newly generates 797 a signing secret key in the hardware wallet, the attacker can use the 798 signature secret It becomes possible to restore the key. 800 8.2.2. Risks related to asset data 802 The asset data is data for managing assets such as Crypto Assets and 803 statutory currency held by customers and custodians. The secret key 804 of the transaction signature shall not be included (see Section 5.2). 805 As mentioned above, since asset data varies from custodians to 806 custodians, we consider this as a more abstracted model in this 807 document. Since detailed threat analysis and risk assessment need to 808 be performed on the asset data handled by the actual custodian 809 system, only the way of thinking is shown here. The main threats of 810 asset data may be illegal rewriting, loss, or leakage. The factors 811 include mis-operation by the manager, malice of the righteous person, 812 spoofing the legitimate person, malicious intent of the outsider, 813 unintended behavior of the system. In the example of the basic model 814 in Section 5.2, there is a route from the exchange management system, 815 the customer property management system, and the incoming coin 816 determination unit. Among the threats of asset data, the following 817 examples are considered as incidents due to illegal rewriting. A 818 customer asset management system referring to unauthorized asset data 819 may create an illegal transaction and flow through the normal process 820 to the block chain (Section 8.2.1.4). For example, it is possible to 821 rewrite the holding amount recorded in the asset data, change the 822 Crypto Assets transfer destination address, or the like. For 823 example, by rewriting the list of addresses associated with the 824 customer, illegal recombination of the amount held between customers 825 or between customers and custodians within the asset data within the 826 custodian will be made. As a transaction in the block chain the 827 result is not reflected, assets that a customer or custodian should 828 have had is lost. Risks related to asset data can be thought of as a 829 problem similar to general financial and settlement systems, but 830 transactions can be canceled if transactions are written to the block 831 chain as a result of fraud against asset data It is necessary to 832 consider it on the premise that there is no property. 834 8.2.3. Risks related to suspension of systems and operations 836 The system of the crypto assets custodian office is software, 837 hardware, network, and the like constituting the crypto assets 838 custodian. In addition, the term "operation" refers to an operation 839 performed manually, such as operation monitoring of a switching 840 center system, account opening, remittance instruction, wallet 841 deposit / withdrawal. It is conceivable that the system and work may 842 be stopped due to various factors. Risks related to suspension of 843 systems and operations can be regarded as problems similar to general 844 financial and payment systems. However, the fact that the crypto 845 assets custodian office is connected to the Internet all the time, 846 not the dedicated communication network at all times, that it is 847 operating 24 hours a day, 365 days, that many crypto assets 848 custodians are built on the public cloud infrastructure, crypto 849 assets custodian It is necessary to consider it based on the fact 850 that the operating situation of the place has a large effect on the 851 crypto assets price and it tends to be an object of attack. 853 8.2.3.1. Risks related to network congestion 855 Crypto assets custodians frequently receive denial of service 856 attacks. As a target of a denial-of-service attack, publicly- 857 released top page, API endpoint, etc. are common, but when an 858 attacker knows the system configuration and a business system or 859 operation monitoring system is placed on the Internet, A case of 860 receiving a denial of service attack may be considered. 862 8.2.3.2. Risk of system outage 864 It is conceivable that the data center, the cloud infrastructure, 865 etc. where the system is installed are stopped, and the system and 866 operations are stopped. The system can be stopped due to various 867 factors such as power outage due to natural disasters and disruption 868 of communication, large scale failure due to mistake by cloud 869 infrastructure operator, large scale system failure due to mistake of 870 infrastructure operation, failure of software release. 872 8.2.3.3. Risks related to Operator 874 Even if the system itself is in operation, if operations monitoring 875 and tasks of personnel responsible for the operation are hindered, 876 the work will be suspended. For example, regular inspections of 877 power facilities at operation bases, disruption of transportation 878 means due to catastrophic changes and strikes, protest activities and 879 rush of press reporters may hinder the entrance and exit of buildings 880 and halt operations. In addition, when personnel are using the same 881 transportation method or participating in the same event, there is a 882 risk that many personnel can not operate due to the same accident 883 such as traffic accident or food poisoning. 885 8.2.3.4. Regulatory risks 887 In countries where the crypto assets custodian office is stipulated, 888 licensing system or registration system, business may be suspended 889 due to business improvement order, business suspension order, 890 deletion of registration etc etc. 892 8.3. Risks from external factors 894 Even if the systems and operations of the crypto assets custodian are 895 appropriately operated, if the blockchain / network in which the 896 crypto assets operates and the Internet infrastructure supporting the 897 connection between the nodes are attacked, On the other hand, the 898 service cannot be continued or the transaction can not be handled 899 properly. 901 8.3.1. Risks related to the Internet infrastructure and authentication 902 infrastructure 904 8.3.1.1. Internet routing and name resolution attacks 906 An attacker interferes with routing of the Internet such as route 907 hijacking and domain name resolution (Domain Name Service), hindering 908 the reachability to the custodians and guiding it to a fake custodian 909 office or block chain It is possible to intentionally cause a branch 910 by hindering synchronization. This method can be considered not only 911 by malicious attackers but also by ISP etc. based on instructions 912 from the government. 914 8.3.1.2. Attacks on Web PKI 916 Many crypto assets custodian offices provide services on the Web, and 917 TLS and server certificates are used for user authenticity 918 verification and encryption of sites. When a certificate authority 919 issuing a server certificate is attacked, it may be possible to 920 impersonate the site, or if the server certificate is revoked, the 921 service cannot be provided. 923 8.3.1.3. Attack on Messaging 925 By intervening with an e-mail or other messaging system, an attacker 926 can fraud and block SMS / MMS of e-mails and mobile phones used for 927 interaction with users and delivery of one-time passwords. When a 928 user's message is fraudulent, it is possible to log in as a user and 929 reset the password. 931 8.3.2. Troubles due to block chains of crypto assets 933 8.3.2.1. Crypto assets blockchain fork, split 935 8.3.2.2. Re-org of Blockchain by 51% attack and selfish mining 936 8.3.2.3. Compromise of hash function and cryptographic algorithm 938 8.3.2.4. Inadequate consensus algorithm 940 By misusing a bug in the agreement algorithm, fake transaction 941 information is sent to a specific node and disguised as to whether or 942 not to send money to the counter party. For example, in the case of 943 the MtGOX case in 2014, double payment attacks abusing Transaction 944 Malleability occurred frequently in piggybacking. 946 8.3.3. Risks arising from external reputation databases 948 8.3.3.1. Establishment of Bank Account Elimination and Freezing 950 As a part of AML / CFT, there are cases where banks refuse to open 951 accounts related to the work of the crypto assets custodian office, 952 the risk that the bank accounts will be frozen, such as receiving 953 guidance from the regulatory authorities or accident is there. In 954 the event that the account is frozen, the business of depositing and 955 withdrawing a legal currency with the user as a crypto assets 956 custodian office is stopped. 958 8.3.3.2. Crypto assets address 960 As a part of AML/CFT, when another crypto assets custodian trader 961 remittles to another crypto assets address, there are cases where it 962 is checked whether the remittance destination address does not 963 correspond to a high risk transaction. In the case where the address 964 of the hot wallet of the custodian office is registered as a 965 problematic address, it is assumed that the custodian of the crypto 966 assets with such a service can not be performed smoothly. Since it 967 is common in many cases that criminal remit crypto assets stolen for 968 disturbance to a known address, there is a risk that the address of 969 the hot wallet of the crypto assets custodian office will be 970 classified as a high risk customer by mistake. 972 8.3.3.3. Filtering and blocking for Web sites 974 There is a risk that the URL of the crypto assets custodian office is 975 filtered by the network or blocked by the ISP so that the user can 976 not access it. Also, if it is recognized as a malware distribution 977 site or the like, there is a risk that it will not be displayed as a 978 search result or it will be impossible to browse from the browser. 980 8.3.3.4. Email 982 As a measure against spam mails, most of mail servers provide mail 983 rejection based on reputation and classification function of spam 984 mails. If the e-mail delivered by the custodian is judged as spam, 985 it may be impossible to contact the user. 987 8.3.3.5. Appraisal of a smartphone application 989 Depending on the platform, there are cases where handling of crypto 990 assets by the application is restricted. If the examination of the 991 smartphone application is dropped, the user may not be able to 992 download the smartphone application for accessing the custodian and 993 may be unable to use the service. 995 8.4. Financial Crime Risks 997 8.4.1. Risk of being abused in criminal acts 999 8.4.1.1. Identity Theft 1001 8.4.1.2. Scams 1003 8.4.1.3. Ransom 1005 8.4.1.4. Utilization for transactions in the dark market 1007 8.4.2. Anti Money Laundering 1009 8.4.3. Counter Financing of Terrorism 1011 9. Consideration on security controls at crypto assets custodian 1013 9.1. General 1015 In this clause, considerations from the ISMS viewpoint in 1016 implementing security controls to crypto assets custodians for risks 1017 described in clause 8 are described. They included issues caused by 1018 specific characteristics to crypto assets. This clause also 1019 describes relationship to [ISO.27001:2013] and [ISO.27002:2013] for 1020 each consideration. 1022 9.2. Consideration on security controls 1024 ### Direction of the information security management 1026 Objectives of security management at a crypto assets custodian 1027 contain secure protection of customer's asset, compliance to business 1028 requirements, laws and rules, and realization of social 1029 responsibility. Security policies and execution statements derived 1030 from such objectives are recommended to be publicly available for 1031 consumers, business partners, auditor and regulators to help their 1032 judge. 1034 9.2.1. Security controls on signing keys 1036 9.2.1.1. Basics of key management 1038 In general, followings are required in management of private 1039 cryptographic keys. 1041 o They should be Isolated from other informational assets. Rigorous 1042 access control is mandatory. 1044 o Limit the number of access to private keys as minimum as possible. 1046 o Be prepared for unintentional lost of private keys. 1048 Followings are three basic security control to realize above. 1049 Additional security controls specific to crypto assets custodians are 1050 described in and after sub-clause Section 9.2.2. 1052 1. State management of private keys 1053 As described in Figure 2, a private key has one of multiple 1054 states, and it may be active or inactive state in its operation. 1055 The private key should be in active state when it is used for 1056 signing or decryption. It is recommended to enforce to input 1057 some secret information to activate an inactive private key. 1058 This makes keep the inactive private key away from abuse, if the 1059 adversary does not have the secret information. This method 1060 ensure security of the private key against leakage and lost. 1061 It is also recommended to minimize the term of activation to 1062 limit the risk of abuse as minimum as possible. Unnecessary 1063 activation of secret key increases the risk of abuse, leakage and 1064 theft, though keeping the activation state is efficient from 1065 business viewpoint. On the other hand, frequent activation/ 1066 inactivation may give impact to business efficiency. It is 1067 important to consider the trade-off between the risk and business 1068 efficiency and provide clear key management policy to customers. 1070 2. Administrator role separation and mutual check-and-balance 1071 It is fundamental form of operation of a critical business 1072 process which uses private key to perform cryptographic 1073 operations by multiple party to prevent internal frauds and 1074 errors. For example, by setting isolated rights on digitally 1075 signing and approval to go into the area of signing operation, it 1076 becomes difficult for single adversary to give an malicious 1077 digital signature without known by the third party. 1078 Additionally, the enforcement of attendance of other person is 1079 effective security control to internal frauds and mis-operations. 1081 3. Backup of private key 1082 Lost of private key makes signing operations by using the key 1083 impossible any more. Thus backup of private key is an important 1084 security control. On the other hand, risks of leakage and theft 1085 of backup keys should be considered. It is needed to inactivate 1086 the backup key. 1088 9.2.1.2. Backup 1090 Backup is the most fundamental and effective measure against lost of 1091 signing key. On the other hand, there are risks of leakage and lost 1092 of backup device. These risks depend on the kind backup device, thus 1093 security controls on such devices should be considered independently. 1094 Followings describe typical backup devices and leakage/theft risks 1095 associated with them. 1097 o Cloning to tamper-resistant cryptographic key management device 1099 If a signing key is managed by a tamper-resistant key management 1100 device (device X) and X has cloning function, cloning the key to 1101 another device Y is the most secure way to backup the key, where the 1102 cloning function is the technique to copy the key with keeping 1103 confidentiality to other devices than X and Y. The implementation of 1104 the function is recommended to be evaluated/certified by 1105 certification program like CMVP or FIPS 140. Note that, the 1106 cryptographic algorithms supported by such tamper-resistant key 1107 management devices are limited and all crypto assets systems can 1108 utilize it, but it is one of the most secure way of backup. 1110 o Backup to storage for digital data 1112 Here, it is assumed to backup keys to storage like USB memory and 1113 DVD. There are two types of operations; one is backup data is stored 1114 in movable devices in offline manner, the other is backup data is 1115 stored in online accessible manner. If the device is movable, the 1116 possibility of steal and lost increases, thus the device should be 1117 kept in a cabinet or a vault with key, and the access control to such 1118 cabinet/vault should be restrict. 1120 Of the backup storage is online, risks of leakage and theft should be 1121 assumed as same as the key management function implementation inside 1122 the crypto assets custodian. In general, the same security control 1123 is recommended to such backup storage. If there is some additional 1124 operation, for example the backup device is inactivated except for 1125 the time of restore, the security control may be modified with 1126 considering operation environment. When it is not avoided the raw 1127 key data is be outside of the key management function implementation, 1128 the custodian should deal with the problem of remained magnetics. 1130 o Backup to paper 1132 There is a way to backup keys in offline manner, to print them to 1133 papers as a QR code or other machine readable ways. It is movable 1134 than storage for digital data and easy to identify. There remains 1135 some risk of leakage and theft by taking a photo by smartphone and so 1136 on. 1138 9.2.1.3. Offline management 1140 There is a type of offline key management (as known as "cold wallet") 1141 which isolates private keys from the system network to prevent 1142 leakage and theft caused by intrusion. 1144 In this case, some offline operation is needed to make the system use 1145 the key. Examples are, keys are usually stored inside a vault and 1146 connected to the system only when it is utilized, and USB memory is 1147 used to data transportation between an online system and an offline 1148 system. If there is not explicit approval process in the offline 1149 operation for key usage, anyone cannot stop malicious transaction. 1150 That is, this solution can prevent lost and theft, however, an 1151 explicit approval process is needed to prevent abuse of keys. 1153 9.2.1.4. Distributed management 1155 It is also a good security control to distribute the right to use 1156 private key to multiple entity. There are two examples; division of 1157 secret key and multi-signature. 1159 o Division of secret key　 Division of the signing key to 1160 multiple parts, then manage them by multiple isolated system is an 1161 effective measure to protect the keys against leakage and theft. 1162 This document does not recommend a specific technique, but 1163 recommends to implement this control based on a certain level of 1164 security evaluation like secret sharing scheme. In that case, 1165 secure coding and mounting penetration test are needed to 1166 eliminate the implementation vulnerabilities. This method is also 1167 effective to backup devices. 1169 o Multi-Signature 1170 This is a signature scheme which requires multiple isolated 1171 signing keys to sign a message. It is effective to protect each 1172 key hold by an entity and signing mechanisms. There are many 1173 different realization of multi-signature and they are different 1174 according to specific crypto assets system. Thus, consideration 1175 on preparing multiple implementations and their interoperation is 1176 need when a crypto assets custodian operate multiple crypto 1177 assets. 1179 9.2.1.5. Other issues 1181 In this sub-clause, following topics will be described. 1183 o Security of wallet implementation 1185 o Monitoring of private key access 1187 o Log audit 1189 9.2.2. Security controls at crypto assets custodian 1191 Following security controls addition to kay management in sub clause 1192 Section 9.2.2 will be described in this sub clause. 1194 o Organization of information security 1196 o Category and management of assets 1198 o Access control 1200 o Communications security 1202 o Operations security 1204 o Physical and environmental security 1206 o System acquisition, development and maintenance 1208 o Consideration in user authentication and providing API 1210 o Flow control in transaction generation 1212 Above controls are described with aligning to [ISO.27002:2013] and 1213 considering security controls specific to crypto assets custodians. 1214 The structure of this sub clause aligns the structure of 1215 [ISO.27002:2013]. 1217 9.3. Countermeasures against risks caused by blockchain and network 1218 environment 1220 9.4. Risk mitigation against crimes 1222 10. Remaining issues 1224 11. Security Considerations 1226 Security Considerations are included in main section of this 1227 document. 1229 12. IANA Considerations 1231 None. 1233 13. References 1235 13.1. Normative References 1237 [ISO.27001:2013] 1238 International Organization for Standardization, 1239 "Information technology -- Security techniques -- 1240 Information security management systems -- Requirements", 1241 ISO/IEC 27001:2013, October 2013, 1242 . 1244 [ISO.27002:2013] 1245 International Organization for Standardization, 1246 "Information technology -- Security techniques -- Code of 1247 practice for information security controls", ISO/ 1248 IEC 27002:2013, October 2013, 1249 . 1251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1252 Requirement Levels", BCP 14, RFC 2119, 1253 DOI 10.17487/RFC2119, March 1997, 1254 . 1256 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1257 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1258 May 2017, . 1260 13.2. Informative References 1262 [I-D.nakajima-crypto-asset-terminology] 1263 Nakajima, H., Kusunoki, M., Hida, K., Suga, Y., and T. 1264 Hayashi, "Terminology for Crypto Asset", draft-nakajima- 1265 crypto-asset-terminology-00 (work in progress), July 2018. 1267 Acknowledgements 1269 Thanks to Masanori Kusunoki, Yasushi Matsumoto, Natsuhiko Sakimura, 1270 Yuji Suga, Tatsuya Hayashi, Keiichi Hida and other members of the 1271 Security Working Group of Virtual Currency Governance Task Force. 1273 Authors' Addresses 1275 Masashi Sato 1276 SECOM Co., Ltd. Intelligent System Laboratory 1277 SECOM SC Center 1278 8-10-16 Shimorenjaku 1279 Mitaka, Tokyo 181-8528 1280 JAPAN 1282 Email: satomasa756@gmail.com 1284 Masaki Shimaoka 1285 SECOM Co., Ltd. Intelligent System Laboratory 1286 SECOM SC Center 1287 8-10-16 Shimorenjaku 1288 Mitaka, Tokyo 181-8528 1289 JAPAN 1291 Email: m-shimaoka@secom.co.jp 1293 Hirotaka Nakajima (editor) 1294 Mercari, Inc. R4D 1295 Roppongi Hills Mori Tower 18F 1296 6-10-1 Roppongi 1297 Minato, Tokyo 106-6118 1298 JAPAN 1300 Email: nunnun@mercari.com