idnits 2.17.1 draft-vcgtf-crypto-assets-security-considerations-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * MUST not use hardware obtained through the untrusted procurement route. -- The document date (16 December 2020) is 1219 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-nakajima-crypto-asset-terminology-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: 19 June 2021 H. Nakajima, Ed. 6 Mercari 7 16 December 2020 9 General Security Considerations for Cryptoassets Custodians 10 draft-vcgtf-crypto-assets-security-considerations-07 12 Abstract 14 This document discusses the technical and operational risks of 15 cryptoassets custodians and its security controls to avoid the 16 unintended transactions for its customers. 18 Discussion Venues 20 This note is to be removed before publishing as an RFC. 22 Source for this draft and an issue tracker can be found at 23 https://github.com/cgtf/draft-crypto-assets-security-considerations. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 19 June 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Scope of this document . . . . . . . . . . . . . . . . . . . 4 60 3. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 61 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Basic description of a model system of a cryptoassets 63 custodian . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5.2. A basic model of cryptoassets custodians system and its 66 functional components . . . . . . . . . . . . . . . . . . 5 67 5.3. The flow leading to the sending of the transaction . . . 7 68 5.4. Types of keys that are used for signature and 69 encryption . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.4.1. Type of keys . . . . . . . . . . . . . . . . . . . . 8 71 5.4.2. Flow for the key generation and key usage . . . . . . 9 72 5.4.3. On the use of multiple keys . . . . . . . . . . . . . 10 73 5.4.4. On the suspension of keys . . . . . . . . . . . . . . 11 74 5.5. Characteristics of cryptoassets in blockchain and 75 distributed ledger . . . . . . . . . . . . . . . . . . . 11 76 5.5.1. About this section . . . . . . . . . . . . . . . . . 11 77 5.5.2. Importance of signature keys . . . . . . . . . . . . 11 78 5.5.3. Diversity of implementations . . . . . . . . . . . . 12 79 5.5.4. Possibility of blockchain forks . . . . . . . . . . . 12 80 5.5.5. Risks for Unauthorized Transactions . . . . . . . . . 13 81 6. Risks of cryptoassets custodian . . . . . . . . . . . . . . . 14 82 6.1. About this chapter . . . . . . . . . . . . . . . . . . . 15 83 6.2. Risks of cryptoassets custodian system . . . . . . . . . 15 84 6.2.1. Risks related to signature keys . . . . . . . . . . . 16 85 6.2.2. Risks related to assets data . . . . . . . . . . . . 22 86 6.2.3. Risks of suspension on system and operation . . . . . 23 87 6.3. Risks from external factors . . . . . . . . . . . . . . . 24 88 6.3.1. Risks related to the Internet, Web PKI, and users 89 environment . . . . . . . . . . . . . . . . . . . . . 24 90 6.3.2. Risks related to cryptocurrency blockchain . . . . . 25 91 6.3.3. Risks from external reputation . . . . . . . . . . . 26 92 7. Considerations of security controls on Cryptoassets 93 Custodians . . . . . . . . . . . . . . . . . . . . . . . 27 94 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 27 95 7.2. Basis for consideration about security management . . . . 28 96 7.3. Considerations about security controls on Cryptoassets 97 custodians . . . . . . . . . . . . . . . . . . . . . . . 28 98 7.3.1. Information security policies . . . . . . . . . . . . 29 99 7.3.2. Organization of information security . . . . . . . . 29 100 7.3.3. Human resource security . . . . . . . . . . . . . . . 29 101 7.3.4. Asset management . . . . . . . . . . . . . . . . . . 29 102 7.3.5. Access control . . . . . . . . . . . . . . . . . . . 30 103 7.3.6. Security controls on signature keys . . . . . . . . . 32 104 7.3.7. Physical and environmental security . . . . . . . . . 37 105 7.3.8. Operations security . . . . . . . . . . . . . . . . . 38 106 7.3.9. Communications security . . . . . . . . . . . . . . . 40 107 7.3.10. Supplier relationships . . . . . . . . . . . . . . . 43 108 7.3.11. Information security incident management . . . . . . 43 109 7.3.12. Information security aspect of business continuity 110 management . . . . . . . . . . . . . . . . . . . . . 43 111 7.3.13. Compliance . . . . . . . . . . . . . . . . . . . . . 45 112 7.4. Other cryptoassets custodians system specific issues . . 45 113 7.4.1. Advance notice to user for maintenance . . . . . . . 45 114 8. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 45 115 9. Security Considerations . . . . . . . . . . . . . . . . . . . 45 116 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 117 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 118 11.1. Normative References . . . . . . . . . . . . . . . . . . 46 119 11.2. Informative References . . . . . . . . . . . . . . . . . 46 120 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 123 1. Introduction 125 This document gives guidance as to what security measure should the 126 cryptoassets custodians consider and implement to protect the asset 127 of its customers. The management of the signature key for 128 cryptoassets especially has different aspects than other types of 129 information systems and requires special attention. 131 This document reports especially on the appropriate management of the 132 signature key by the cryptoassets custodians to avoid the unintended 133 transactions for its customers. 135 The document organizes recommendations for considering security as a 136 purpose of protecting users' assets by operators of cryptoassets 137 custodians. Among the assets to be protected, in particular, the 138 signature key of the cryptoassets has a different characteristic from 139 the conventional information system and needs attention. Particular 140 emphasis is given to points that should be kept in mind for the 141 cryptoassets custodians to properly manage the signature key and to 142 prevent illegal transactions that the customer does not intend. 144 The basic model of the cryptoassets custodians system covered in this 145 document is shown in Section 5. A system in a form different from 146 this basic model, for example, a system where an operator manages a 147 signature key provided by a user (e.g. online wallet), is handled in 148 another complementary document or later revision of this document. 150 2. Scope of this document 152 An operator covered by this document is a cryptoassets custodian that 153 manages the signature key used in the cryptoassets. Including the 154 case where the management of the signature key is entrusted to 155 another custodians operator. In that case, even for operators 156 entrusted with the management of signature key, a considerable part 157 of the recommendation indicated in this document is considered to 158 apply. 160 This document includes considerations on threats and risks for the 161 following subjects. 163 * A cryptoassets custodians system that provides cryptoassets 164 custodians work to customers (consumers and other exchanges) 166 * Assets information managed by the cryptoassets custodians system 167 (including the signature key of the cryptoassets) 169 * The social impact which can be exerted by imperfect security 170 measures of the cryptoassets custodians system 172 This document does not focus on the following items. 174 * Security measures for information systems used by daily operations 175 by custodians operators 177 * Security measures against blockchains that provide the mechanism 178 of cryptoassets and distributed ledger itself 180 * Operator's own management risk 182 * Specific requirements on separation of assets of customers and 183 custodians/exchanges 185 3. Conventions and Definitions 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 189 "OPTIONAL" in this document are to be interpreted as described in 190 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 191 capitals, as shown here. 193 4. Terminology 195 Terms used in this document are defined in 196 [I-D.nakajima-crypto-asset-terminology] 198 5. Basic description of a model system of a cryptoassets custodian 200 5.1. General 202 In this section, a model of a cryptoassets custodians system that is 203 used to explain the concepts and provisions in this document are 204 explained. 206 5.2. A basic model of cryptoassets custodians system and its functional 207 components 209 Followings are the basic model of a crypto assets custodian that this 210 document deals with. A basic model of cryptoassets custodians system 211 is shown on Figure 1. 213 (Artwork only available as svg: No external link available, see 214 draft-vcgtf-crypto-assets-security-considerations-07.html for 215 artwork.) 217 Figure 1: Basic Model of Cryptoassets Custodians system 219 * Interface (Web Application, APIs) Provides screen and input 220 functions such as login process, account management (deposit/ 221 withdrawal instruction etc.) and trade instruction for the 222 customers(users). Web application, API, etc. 224 * Customer Authentication Function Performs user authentication 225 process for login to the cryptoassets custodians. 227 * Customer Credentials Manages required IDs for login and 228 verification information related to user authentication process 229 (e.g. password verification info.). 231 * Customer Assets Management Function A group of functions to manage 232 customer accounts. Receive instructions for deposit or withdrawal 233 (outgoing coins) and perform processing according to the user 234 instructions. Retrieve or update assets data. 236 * Blockchain Node Connects to another blockchain nodes to retrieve 237 blockchain data. 239 * Incoming Coin management Function Checks transaction stored in 240 blockchain and confirm whether incoming coins are involved in the 241 specified addresses. Update an assets database according to the 242 transaction from blockchain. 244 * Order processing function A group of functions that receives 245 orders from customers and performs processing related to trading 246 of cryptoassets. Retrieves and updates assets data based on the 247 orders. 249 * Assets Database Manages holdings of fiat currencies and 250 cryptoassets. The database does not include the private keys for 251 transaction signature. Assets are managed separately from the 252 assets of the custodian for each customer. 254 * Transaction Singing Function 256 - Transaction Generator Generates transactions to be sent to the 257 blockchain based on instructions from the customer asset 258 management function or the custodians operation function. 260 - Transaction Broadcaster Broadcasts the signed transaction to 261 the blockchain. Connects to other nodes on the blockchain. 263 - Transaction Signing Function Generates digital signatures based 264 on the instructed transaction contents and the signature key 265 (or its IDs and its addresses). 267 - Address Management Manages public keys with related to the 268 signature keys, or addresses (such as values calculated from 269 the public keys). 271 - Signature Key Management Function Manages the signature keys of 272 the cryptoassets (keys used for signing the transaction). 273 Sometimes signature keys are separately stored into the cold- 274 wallet as security countermeasure. 276 - Signature key generator Generates signature keys. The 277 generated keys are registered in the signature key management 278 function, and the public keys and addresses are registered in 279 the address management function. 281 * Custodians Operation Modules A group of functions for custodians' 282 operators or administrators. Based on operations from 283 administrators, the module instructs generating new signature keys 284 or transferring cryptoassets. 286 * Operator Authentication Function Authenticates the administrators. 288 * Operator Audit Database Manages auditing data related to the 289 authentication of the administrators. 291 We defined each functional element to distinguish functions 292 logically, and do not show the actual arrangement on the actual 293 system. For example, in our actual system, the address management 294 unit may be managed by an integrated database. Also, there are 295 implementations with multiple functions packaged together. For 296 example, each functional element of the transaction signature system 297 may be integrated with the customer property management system, or 298 the transaction signature system may be operating as another system. 300 When using existing implementations such as bitcoin wallet, bitcoin 301 wallet is thought to provide the functions of the transaction 302 signature system as just one implementation as a whole. It is also 303 conceivable that some functions are provided by a remote 304 subcontractor as in a form in which the function of the transaction 305 signature system is provided by a remote server. 307 5.3. The flow leading to the sending of the transaction 309 * Deposit Phase 311 1. Customers send fiat to custodian's bank account. 313 2. Custodians shall confirm to receive fiat, and shall update 314 assets database to reflect customer asset information. 316 * Input coin phase 318 1. Customer transfer cryptoassets to the address instructed by 319 custodians. The transfer shall be made by cryptoassets wallet 320 for the customer such as tools or services (other custodians 321 or Web wallet) 323 2. Custodians shall confirm cryptoassets has been transferred to 324 the address instructed and shall update the asset database to 325 reflect asset information of the customer. 327 * Trading phase 329 1. Customer access to interfaces to make instructions. 331 2. Instructions to transfer shall be processed by custodians 332 operations functions. The result of trade processed by 333 custodians operations functions shall be updated into the 334 asset database. 336 * Instructions to output coins from customers 338 1. Customers access to interface and instruct it to transfer its 339 cryptoassets to other address. (Instruct to output coins) 341 2. Instructions to output coins shall be processed by customer 342 assets management functions. Transaction generator shall make 343 transaction messages based on instructions such as receive 344 address or amount of cryptoassets. 346 3. Transaction messages shall be added a digital signature by 347 transaction signing functions. 349 4. Transaction messages with a digital signature shall be 350 delivered to all nodes on blockchain by transaction 351 broadcaster. 353 * Instruction to transfer from Customer Assets Management Function 355 1. Administrator instructs to send cryptoassets to address 356 through the interface of Management Functions. For Example, 357 it may send between address managed inside custodians. 359 2. Instructions to transfer shall be processed on Management 360 Function, and shall be processed as described 2 to 4 on 361 "output coin". Transactions with digital signature shall be 362 delivered to all nodes on blockchain. 364 5.4. Types of keys that are used for signature and encryption 366 5.4.1. Type of keys 368 +===============+===============================================+ 369 | Types | Description | 370 +===============+===============================================+ 371 | Signature Key | A private key for signing transactions | 372 | | (asymmetric key cryptography) | 373 +---------------+-----------------------------------------------+ 374 | Verification | A public key for verification of transactions | 375 | Key | (asymmetric key cryptography). Recipient | 376 | | address of transactions are the unique value | 377 | | calculated from verification key | 378 +---------------+-----------------------------------------------+ 379 | Encryption/ | Secret key used to keep signature key | 380 | decryption | (symmetric key cryptography) confidential / | 381 | key for | protected | 382 | signature key | | 383 +---------------+-----------------------------------------------+ 384 | Master Seed | A seed, e.g. random number, to generate a | 385 | | signature key in deterministic wallet | 386 +---------------+-----------------------------------------------+ 388 Table 1: Type of keys 390 5.4.2. Flow for the key generation and key usage 392 (Artwork only available as svg: No external link available, see 393 draft-vcgtf-crypto-assets-security-considerations-07.html for 394 artwork.) 396 Figure 2: Lifecycle of signature key, verification key and 397 encryption/ decryption key for signature key 399 After a pair of keys (signature & verification, hereafter "key pair") 400 is generated, an addressed to receive transaction is derived from the 401 verification key. By providing a sender of digital assets this 402 address, the sender is able to transfer one or more assets to this 403 address. When the recipient transfers the assets to another address, 404 the original recipient signs the transaction data which includes the 405 transfer order. 407 A signature key is considered to be in an inactive state when it is 408 stored in a confidential manner (ie. cannot be directly used to 409 sign), for example within the key management function in Figure 1. 410 An example of how to set a signature key in an inactive state is to 411 encrypt the signature key using an encryption key (ie. passphrase). 413 The opposite process of decrypting the signature key will return the 414 key inactive state. The activation of a key is assumed to be 415 executed within the transaction signing function in Figure 1. 417 Activation and deactivation of keys is part of the function set of 418 certain wallets. 420 The signature key is not needed after its generation until a 421 transaction has to be signed. Therefore this allows for the store 422 and manages signature keys offline while keeping the verification key 423 and addresses online (See: Section 7.3.6.2). 425 (Artwork only available as svg: No external link available, see 426 draft-vcgtf-crypto-assets-security-considerations-07.html for 427 artwork.) 429 Figure 3: Lifecycle of signature key, verification key and 430 encryption/ decryption key for signature key in case of 431 deterministic wallet 433 The deterministic wallet is a mechanism that generates one master 434 seed and generates multiple signature key pairs from that master 435 seed. It is possible to regenerate each signature key pair from the 436 master seed by backing up the master seed and restoring it. On the 437 other hand, if the master seed is stolen, the crypto assets which are 438 managed by all signature key pairs (and addresses) derived from the 439 master seed may be stolen. Also, if the master seed is lost, all 440 signature key pairs will not be able to be regenerated. 442 As an extension of the deterministic wallet, there is a hierarchical 443 deterministic wallet (HD wallet). In the case of HD wallet, a master 444 key pair is created from the master seed, and child key pairs are 445 derived from the master key pair. Furthermore, descendant key pairs 446 can be derived from the child key pairs in a hierarchical manner. 447 Since the child key pair can be created from the parent key pair, it 448 is not necessary to access the master seed when generating the child 449 key pair. The implementation of hierarchical key pair generation 450 depends on the signature algorithm, and some currencies cannot be 451 realized in principle. Although this document refers mainly to the 452 management of the signature keys in the security control measures, 453 the master seed also needs security management equal to or higher 454 than the signature keys. 456 5.4.3. On the use of multiple keys 458 There are some cases to use cryptoassets where one user uses one 459 address, one user uses multiple addresses. The number of addresses 460 and pairs depends on the number of cryptassets and method of 461 management. For example, cryptoassets that can contain tags related 462 to the transaction such as Ripple and NEM, cryptoassets custodian may 463 distinguish customers by each tag if custodian uses one address. On 464 the other hand, cryptoassets that cannot contain any tags for 465 transactions, custodians have to make addresses for each customer, so 466 the number of addresses and key pairs would be increased. It is 467 considered to use multiple addresses and key pairs by risk evaluation 468 with not only a variety of cryptoassets (e.g., Bitcoin, Ethereum, 469 etc.) but also management by the hot wallet and cold wallet. 471 It is recommended not to reuse key pair for general. But it is 472 focussed for anonymous transactions by private use, so this is not 473 suitable for custodians from viewpoint of efficiency and 474 practicality. Cryptoassets custodians shall make effective controls 475 considered by risk evaluations and control objective. 477 5.4.4. On the suspension of keys 479 Even if Figure 2 indicates operations on operations of custodian, 480 cancellation of transaction cannot be made for cryptoassets. Also, 481 it is difficult to revoke the signature key after suspension of using 482 keys. For example, it may happen to input coins to the address user 483 has suspended to use. To return coins to the sender, custodian needs 484 a signature key for the suspended address. cryptoassets custodians 485 shall assume those cases, and shall consider about revoking signature 486 keys carefully. 488 5.5. Characteristics of cryptoassets in blockchain and distributed 489 ledger 491 5.5.1. About this section 493 In the handling of cryptoassets using blockchain / distributed 494 ledger, there are things to emphasize and different characteristics 495 compared with general information systems and usages of private/ 496 encryption keys. In considering the risk assessment described in 497 Section 6 and the security requirements and measures based thereon, 498 it is necessary to pay attention to these characteristics. 500 5.5.2. Importance of signature keys 502 As described in Section 5.3, by signing transactions using the 503 signature keys, it is possible to instruct the transfer of the values 504 of cryptoassets to other addresses. Once this transaction is written 505 to the block or ledger data and the transfer of the values of 506 cryptoassets is approved it is difficult to revert it or to 507 invalidate the transfer by revocation procedure etc. This property 508 is in contrast to taking time until the remittance gets caught or the 509 process can be canceled during remittance and be reassembled, even if 510 it requires complicated administrative procedures in the process of 511 remittance, and illegal remittances occur. In addition, when the 512 private signature keys have vanished in the cryptoasset scheme, there 513 will be a case that the cryptoasset held by the address corresponding 514 to the signature private key is impossible to transfer to the other. 515 In cryptoassets having such irreversible nature, it must pay 516 attention to the theft, fraudulent use and disappearance of the 517 signature secret key. 519 5.5.3. Diversity of implementations 521 There are various cryptoassets including Bitcoin. The specifications 522 also vary widely from cryptoassets to cryptoassets. For example, 523 there are differences in the using of encryption algorithms, hash 524 functions, the methods of generating/spreading transactions, and 525 wallet implementations to protect the signature key(s), and so on. 526 Due to these differences in specifications, effective countermeasures 527 for a specific cryptoasset may not be able to be carried out under 528 the specification of another cryptoassets. And also, from the 529 current feaver trends of the cryptoassets, the appearance of new 530 cryptoassets and the speed of functional expansion and specification 531 change of existing cryptoassets mechanisms are very fast. 533 5.5.3.1. Cryptographic algorithm of cryptoassets 535 There are cases that new cryptographic algorithms in cryptoassets 536 that are not sufficiently reviewed for security may be adopted. In 537 ordinary use cases of cryptography technology, designers often use 538 cryptographic algorithms that are scientifically verified, 539 mathematically proved secure, and approved by official authorities/ 540 agencies, however, cryptoassets designers are often adopting 541 "immature and unverified" cryptographic algorithms. This means that 542 it takes time to archive provable security for algorithms and approve 543 by official authorities/agencies, while in the blockchain where 544 competition and evolution are remarkable, the maturity level is low 545 as technology, and differentiation and blocking from other 546 cryptoassets. It must be optimized the technology specific to the 547 chain. These algorithms are likely to have no properly reviewed 548 implementation, or the risk of a vulnerability being discovered later 549 and compromising (compared to mature algorithms) is high. 551 5.5.4. Possibility of blockchain forks 553 In the blockchain using Proof-of-Work and the like typified by 554 bitcoins, a state such as a temporary fork of a chain due to 555 specification change of software or a single chain of branched chains 556 (re-organization) can arise. Also, as another case, due to the 557 division of the developer community, blockchains are divided from the 558 point of time and sometimes operated as separate cryptoassets. In 559 the real world, there are various forks, it may be difficult to 560 respond to all of them, and it should be consider countermeasures 561 according to the risks. 563 5.5.4.1. Rolling back due to re-organization 565 If the chain is discarded due to a reorganization, the history of 566 transactions contained in the discarded chain will be lost. In that 567 case, the transaction on the block discarded within the 568 reorganization period may not be reflected in the main-chain. 570 5.5.4.2. Handling forks of cryptoassets 572 As in the case of bitcoins and ether symbols, blockchains are divided 573 and sometimes managed as another cryptoassets (here, called a fork 574 coin). The fork coin is also derived from the same software as the 575 original cryptoassets and uses the same technology and compatible 576 technology (A description that incorporates the case where different 577 technologies are adopted for a fork is necessary). In addition, the 578 chain until just before splitting has exact identical data. By using 579 its functionality, it becomes possible to attack, for example, replay 580 attacks. A replay attack is an attack in which transactions used in 581 the original cryptoassets are retransmitted to the sender of the 582 transaction at the fork coin chain and the fork coin is illegally 583 acquired as a result. In this kind of replay attacks, 584 countermeasures such as monitoring of the transaction sender, for 585 fork coin chain, measures to be sent before transactions that return 586 coins to their own other address are required. 588 In addition, if a fork coin occurs in the cryptoassets held by the 589 exchanger, there is also a problem that the fork coin is not returned 590 to the user unless the fork coin is assigned to the user of the 591 exchanger in the exchange system. 593 5.5.5. Risks for Unauthorized Transactions 595 5.5.5.1. About this section 597 Just by sending the transaction instructing the transfer of the 598 coins(assets) to the node of the blockchain does not instantly 599 reflect the cryptoassets transfer. In order for a transaction to be 600 approved, it is stored in a block created every decided period and 601 needs to be accepted by the majority of mining nodes. It may be 602 difficult to confirm that the transaction has been approved for the 603 following reasons. 605 5.5.5.2. Handling unapproved transactions 607 In a cryptasset using a distributed ledger, there are a variety of 608 cryptoassets (such as Bitcoin, Ethereum, etc.) that the transaction 609 sender sends transactions with a transaction fee. This transaction 610 fee is acquired by the miner who creates the block, and the higher 611 the transaction cost, It is easy to store in blocks (transactions are 612 easily approved immediately). If the cost of the transaction sent 613 from the cryptoassets custodian to the blockchain is low, it may take 614 times to approve the transaction, or there is a possibility that the 615 time will expire without being approved. Besides the case due to the 616 transaction fee, the temporary chain fork as in Section 5.5.4.1 can 617 be occurred that the transaction that should have been approved once 618 becomes the unapproved state and the dual spend of cryptoassets. In 619 usage scenes where cryptoassets transfer is required immediately, 620 such as payments in real stores, it may be difficult to take time to 621 confirm the approval of the transaction, and it is necessary to 622 assume the risk of unauthorized transactions. 624 5.5.5.3. Transaction failure due to vulnerabilities from cryptoassets 625 specifications and implementations 627 Although it is not exactly the case of unauthorized transactions, 628 there was a vulnerability called transaction malleability as a past 629 case of bitcoins. With this vulnerability, if the node relaying the 630 transaction is malicious, it is also possible to make transactions 631 illegally manipulate, thereby making it impossible to find the 632 transaction stored in the block (make it impossible to search by 633 transaction ID). There is also the possibility of an attack that 634 makes a duplicate by requesting transmission of the cryptoassets 635 again from the counterparty by making the approved transaction appear 636 as not approved. This attack is performed after sending the 637 transaction to the nodes, so it is characteristic that the sender can 638 not take measures beforehand before sending. Regarding transaction 639 malleability, it is now possible to avoid it by using SegWit in 640 bitcoins. However, as a lesson from this case, effective defense 641 measures cannot be made effective only with the cryptoassets 642 custodian that becomes the sender or receiver of the cryptoassets 643 with respect to faults and threats due to another vulnerability of 644 bitcoins and other cryptoassets. 646 6. Risks of cryptoassets custodian 647 6.1. About this chapter 649 Below in this section, some risks custodian shall consider for the 650 system and for foreign factor outside of control from custodian such 651 as blockchain is described. The risks for systems in custodians are 652 listed as a threat, factor, and actor may cause threat. The risks 653 for foreign factor outside of control from custodian such as 654 blockchain are listed from the incident. Some risks may be caused by 655 property or quality described in Section 5.5. 657 On the other hand, there are some risks based on operations or 658 systems implemented by each custodians. Custodians shall pick up 659 risks to deal with control to refer these risks with understanding 660 with system or operation of custodian. Custodians shall evaluate 661 impacts may be affected by risks and shall decide controls and its 662 priority. 664 6.2. Risks of cryptoassets custodian system 666 In this section, major risks regarding information asset which 667 cryptoassets custodian system holds are listed. Among the 668 fundamental model shown in Section 5, the signature key and asset 669 data are focused as significant information asset to protect 670 customers asset. 672 The attacker may be able to broadcast a malicious transaction to 673 nodes of distributed-ledger after generating the transaction if the 674 signature key and surrounding environment are not safe. 676 Withdrawing transaction is almost impossible once the malicious 677 transaction has been broadcasted and built into the blockchain. 678 Therefore, prior countermeasures to prevent generating malicious 679 transaction are essential. 681 Moreover, consideration of a loss of signature key is also essential. 682 Cryptoassets stored in the address associated with the signature key 683 become unavailable in a case where the signature key has been lost. 685 Risk regarding the signature key including the signature key and 686 surrounding environment are mentioned in Section 6.2.1 based on 687 Figure 1. 689 In this document, the model is described as more abstract as the 690 content of data, data format, management model or details of 691 processing regarding asset data varies among custodians. Record such 692 as client assets (both cryptoassets and fiat currency), assets of 693 custodians(both cryptoassets and fiat currency), clients' account 694 information, or address of cryptoassets is listed as common content 695 of asset data subject to protection. Manipulation to those asset 696 data caused by the attacker results in damage to client assets or 697 affect to the custodians' operation. Risks related to assets data 698 are discussed in Section 6.2.2. 700 Risks of system outage MUST be considered concerning availability 701 which allows clients to control their assets in addition to the 702 protection of important information such as the signature key or 703 assets data. Risks of system control are discussed in 704 Section 6.2.3.2. 706 In addition to information or risks mentioned in this section, system 707 specific risks varied among cryptoassets custodian or risks regarding 708 external contractor MUST be considered. Detailed risk analysis MUST 709 be performed against the actual system of the cryptoassets custodian. 711 6.2.1. Risks related to signature keys 713 Both role and risks of signature keys are extremely large on 714 cryptoasset exchange. Signature keys enable to transfer coins, but 715 it comes from properties of difficulties for revocation of lost, 716 leakage, stolen, and rollback transaction. Some risks about 717 signature keys are listed in this section. In addition, risks about 718 supply chain related to risks install wallets handles signature keys. 720 6.2.1.1. Risk analysis related to signature key 722 Risk analysis may depend on threats assumption, the structure of the 723 system, and threats model, the results for each custodians shall be 724 different. Some case studies are described in this section. 726 Threats for signature keys and its actors are assumed as listed 727 below. And actors are assumed as the input of signature key in 728 Figure 1. 730 * Threats: 732 - Loss 734 - Leakage, Theft 736 - Unauthorized Use 738 * Factors of Threats: 740 - Error in operation 742 - Maliciousness (of legitimate person) 743 - Spoofing (for legitimate person)) 745 - Malicious intentions of outsiders 747 - Unintended behavior (system) 749 * Actors: 751 - Custodians operation modules 753 - Transaction Signing modules 755 - Customer assets management function 757 - Incoming Coin management function 759 Factors of threats are organized as follow. 761 Error in operation: A human error caused by an authorized user 762 (including an administrator) during operation of the system. For 763 example, the expected operation was to withdraw coin equivalent to 764 100,000 JPY. But, the actual operation is withdrawing coin 765 equivalent to 1,000,000 JPY. 767 Malicious acts by authorized person: An act committed with malice by 768 an authorized person (including an administrator). For example, 769 theft or unauthorized use of the signature key by the insider. 770 Purpose or incentive of the act is not concerned. 772 Spoofing(of authorized person): Impersonation with a stolen 773 credential of an authorized person. For example, the order to 774 sell/buy/transfer cryptoassets by an external attacker impersonating 775 a client; the malicious order of transfer or generation/signing of a 776 transaction through access to the system with the legitimate 777 operator/administrator credential by an unauthorized insider. 778 Especially, theft and abuse of credential upon an account 779 registration by impersonating a legitimate user MUST be considered. 780 Note: Impersonation which is not caused by theft of legitimate user/ 781 authorized person's credential (e.g., Privilege escalation) are 782 mentioned in "malicious acts by outsiders." 784 Malicious acts by outsiders: Access or operation to the system by 785 outsiders with malicious purpose excluding spoofing. (e.g., external 786 unauthorized access by exploiting a vulnerability; remote access to 787 the system which enables outsiders to operate to the signature key or 788 generate a transaction by a targetted attack to an administrator of 789 the custodians' system.) 790 Unintended behavior: An unintended behavior of the system regardless 791 of intention or malice. (e.g., leakage of the signature key caused by 792 bugs of the system, generation of a transaction including an 793 incorrect amount of assets regardless of operation.) 795 Theft and unauthorized use are threats that can only be caused by a 796 clear malicious factor. Risks to be considered as a result of 797 threats are listed in Table 2. Please note that theft and 798 unauthorized use could happen in a case where multiple factors such 799 as an error in operation or unintended behavior have occurred. (e.g., 800 insertion of backdoor that transmits a signature key or tampers a 801 signing order to the transaction in conjunction with a specific 802 legitimate operation.) This case can be covered in countermeasures 803 of theft or unauthorized use. 805 +=================+===============+====+=======+=====+==============+ 806 | Risk |Factor |Loss|Leakage|Theft| Unauthorized | 807 | | | | | | Use | 808 +=================+===============+====+=======+=====+==============+ 809 | Illegal |End user's |Y |Y |Y | Y | 810 | operation(Route |malicious | | | | | 811 | is legitimate) |operation | | | | | 812 +-----------------+---------------+----+-------+-----+--------------+ 813 | |Malicious |Y |Y |Y | Y | 814 | |operation by | | | | | 815 | |the | | | | | 816 | |administrator | | | | | 817 | |of customer | | | | | 818 | |assets | | | | | 819 | |management | | | | | 820 | |function | | | | | 821 +-----------------+---------------+----+-------+-----+--------------+ 822 | |Impersonation |Y |Y |Y | Y | 823 | |to end users | | | | | 824 +-----------------+---------------+----+-------+-----+--------------+ 825 | |Insider |Y |Y |Y | Y | 826 | |impersonating | | | | | 827 | |an | | | | | 828 | |administrator | | | | | 829 +-----------------+---------------+----+-------+-----+--------------+ 830 | Intrusion from |Intrusion into |Y |Y |Y | Y | 831 | outside |Tx signing | | | | | 832 | |function | | | | | 833 +-----------------+---------------+----+-------+-----+--------------+ 834 | |Intrusion into |Y |Y |Y | Y | 835 | |incoming coin | | | | | 836 | |management | | | | | 837 | |function | | | | | 838 +-----------------+---------------+----+-------+-----+--------------+ 839 | |Intrusion into |Y |Y |Y | Y | 840 | |customer asset | | | | | 841 | |management | | | | | 842 | |function | | | | | 843 +-----------------+---------------+----+-------+-----+--------------+ 844 | |Intrusion into |Y |Y |Y | Y | 845 | |custodian | | | | | 846 | |operation | | | | | 847 | |function | | | | | 848 +-----------------+---------------+----+-------+-----+--------------+ 849 | Incorrect |Unintended |Y |Y |- | - | 850 | behavior is |behaviors of Tx| | | | | 851 | different from |signing | | | | | 852 | operation |function | | | | | 853 | instruction | | | | | | 854 +-----------------+---------------+----+-------+-----+--------------+ 855 | |Unintended |Y |Y |- | - | 856 | |behaviors of | | | | | 857 | |incoming coin | | | | | 858 | |management | | | | | 859 | |function | | | | | 860 +-----------------+---------------+----+-------+-----+--------------+ 861 | |Unintended |Y |Y |- | - | 862 | |behaviors of | | | | | 863 | |customer asset | | | | | 864 | |management | | | | | 865 | |function | | | | | 866 +-----------------+---------------+----+-------+-----+--------------+ 867 | |Unintended |Y |Y |- | - | 868 | |behaviors of | | | | | 869 | |custodian | | | | | 870 | |operation | | | | | 871 | |function | | | | | 872 +-----------------+---------------+----+-------+-----+--------------+ 873 | Human error |Error in |Y |Y |- | - | 874 | |operation by | | | | | 875 | |end user | | | | | 876 +-----------------+---------------+----+-------+-----+--------------+ 877 | |Error in |Y |Y |- | - | 878 | |operation by | | | | | 879 | |administrator | | | | | 880 | |of customer | | | | | 881 | |asset | | | | | 882 | |management | | | | | 883 | |function | | | | | 884 +-----------------+---------------+----+-------+-----+--------------+ 885 Table 2: List of possible risks for the signature key, Y means 886 applicable risk exists, - means no applicable risk exists 888 The following sections outline each risk. The control measures 889 corresponding to each risk are shown in Section 7.3. 891 6.2.1.2. Risk of loss of signature key 893 Risks listed below are an event which causes loss of the signature 894 key from a viewpoint of input to the signature key such as order or 895 operation. 897 As a typical event, the loss of the signature key caused by human 898 error in operation by the administrator of the custodians' system may 899 be considered. 901 6.2.1.3. Leakage and theft risk of signature key 903 In most case, theft is caused by the operation of a malicious person. 904 By contrast, leakage could happen by error or fault not requiring the 905 malice. Therefore, the risk of theft and the risk of leakage MUST be 906 separately considered. 908 The risks of leakage shown in Table 2 are lists of the event which 909 potentially causes leakage of the signature key including the leakage 910 caused by error/fault regarding the input to the signature key such 911 as an order or an operation. For example, an internal criminal, 912 unintentional behavior of the system and intrusion to the system. 914 Likewise, the risks of theft are lists of the event which potentially 915 causes the theft of the signature key by a malicious person. For 916 example, an internal criminal and intrusion to the system. 918 Regarding the leakage of sensitive information to the outside, both 919 leakage and theft are similar, and the countermeasures are the same. 920 The countermeasures are discussed in Section 7.3.6. 922 6.2.1.4. Risks of unauthorized use of the signature key 924 The risks of unauthorized use shown in Table 2 are lists of the event 925 which causes unauthorized use by a malicious person. For example, 926 spoofing of the authorized person and intrusion to the system. 928 Unauthorized use of the signature key could be caused by unauthorized 929 operation of pre-processes of an unsigned transaction at transaction 930 signing function in addition to the direct unauthorized use of the 931 signature key. Following example shows unauthorized use at an early 932 stage of the process. 934 * A destination address of cryptoassets or amount of assets is 935 manipulated due to tampering of software at transaction signing 936 function. The tamper disables designed validation process at the 937 transaction signing function. 939 * A destination address of cryptoassets or amount of assets is 940 manipulated due to tampering of the unsigned transaction generated 941 by transaction generator. Besides, an unauthorized transaction 942 has generated and given to the transaction signing function. 944 * A destination address of cryptoassets or amount of assets is 945 manipulated due to tampering of software at transaction generator. 946 An unsigned transaction has generated with an unauthorized direct 947 operation to transaction generator. 949 * An incorrect amount or incorrect destination address of 950 cryptoassets has transmitted from custodian operation function 951 through transaction generator due to an internal crime, error in 952 operation, or spoofing of the identity by the administrator. 954 * Assets database has tampered in a case where the operation/order 955 to transaction generator refers to the assets database. (See: 956 Section 6.2.2) 958 As shown in the above example, the attacker is able to obtain 959 cryptoassets without attacking to the signature key illicitly. In 960 particular, countermeasures MUST be considered in a case where the 961 system automates each process. 963 Security control measures to the signature key MUST be performed. 964 Moreover, security control measures to the entire custodian's system 965 MUST be performed against these complex risks. Security control 966 measures are discussed in Section 7. 968 6.2.1.5. Other risks 970 6.2.1.5.1. Supply chain risk of hardware wallet 972 Hardware-wallet is known to have a function to manage signature keys. 973 In most hardware-wallet, key administration is done on an 974 administrative terminal connecting via USB such as PC. 976 Cryptographic module validation program for products having a 977 cryptographic key management function such as FIPS 140-2 are 978 provided. However, most of the cryptographic algorithms used in 979 cryptoassets are not covered by those validation programs. 980 Therefore, third-party safety validation program subject to hardware- 981 wallet for cryptoassets is not well provided. For this reason, the 982 users of hardware-wallet MUST understand that safety level of the 983 hardware-wallet available at a market differs among the product. 985 Furthermore, the safety could be threatened by tampering the product 986 during distribution channel even though the product has a certain 987 level of safety in the factory. For example, hardware-wallet 988 tampered in a distribution channel to have a malware enables the 989 attacker to restore the signature key generated by a legitimate owner 990 without acquiring the hardware-wallet. 992 6.2.2. Risks related to assets data 994 Assets data is data to manage an amount of cryptoassets/fiat 995 currencies held by clients or custodian itself. The signature key 996 for transaction signing is not recorded in the assets data. (See: 997 Section 5.2) 999 As mentioned earlier, assets data differs among the custodians, an 1000 abstracted model is used in this section. In this section, a brief 1001 thought is given since detailed threat assessment and risk analysis 1002 MUST be performed against assets data of the actual custodians' 1003 system. 1005 Major threats to the assets data are unauthorized manipulation, loss, 1006 and leakage. The factors are an error in operation by the 1007 administrator, malicious acts by the authorized person, spoofing of 1008 the authorized person, malicious acts by outsiders, and unintended 1009 behavior of the system. 1011 In a case of the basic model shown in Section 5.2, attack surfaces 1012 are custodian operation function, assets database, and incoming coin 1013 management function. 1015 Following example shows the incidents caused by unauthorized 1016 manipulation among the risks to assets data. 1018 * An incident that the malicious transaction generated by assets 1019 database which refers manipulated assets data has broadcasted 1020 through a legitimate process. (See: Section 6.2.1.4) 1022 * Unauthorized manipulation to a number of assets stored in asset 1023 data between clients and/or between clients and custodians by 1024 tampering a list of cryptoassets address linked to clients. This 1025 enables losing assets of clients or custodians without 1026 broadcasting the transaction to the blockchain. 1028 Risks of assets data may be considered as risks of system in 1029 financial service and settlement service. However, countermeasures 1030 to the incident that transaction(s) has merged into blockchain as a 1031 result of unauthorized manipulation to the assets data MUST be 1032 considered with an understanding that transaction broadcast to the 1033 network is irreversible. 1035 6.2.3. Risks of suspension on system and operation 1037 Cryptoassets custodians' systems are composed of software, hardware, 1038 networks. Operations are classified as monitoring, opening an 1039 account, an order of transfer, deposit/withdrawal of (crypto/fiat) 1040 assets from the wallet, and any operations by the operator. The 1041 system may be suspended due to various factors. 1043 Cryptoassets custodians' system tends to be a subject to the attack 1044 due to following: the systems are connected to the Internet for 24 1045 hours 365 days, not by the leased line, many of the systems are 1046 deployed on cloud services, prices of cryptoassets are effected from 1047 operating condition of the cryptoassets custodians. Therefore, 1048 countermeasures to the attack MUST be considered. 1050 6.2.3.1. Risks related to network congestion 1052 Cryptoassets custodians may be attacked by DoS and traffic flooding. 1053 In general, targets of attack are a top page of the Website, API 1054 endpoint, etc., but operation and monitoring system deployed on the 1055 Internet may be a target of DoS attack in a case where the attacker 1056 acquired the information of the system beforehand. 1058 6.2.3.2. Risks of system suspension due to infrastructure 1060 System and operation may be suspended in a case data center or cloud 1061 infrastructure where custodian's system is deployed are suspended. 1062 The system may be suspended due to various factors such as blackout 1063 and disruption of communication due to acts of nature, due to 1064 operation failure by cloud or infrastructure, and failure of software 1065 release. 1067 6.2.3.3. Risks of system suspension due to the operator 1069 Even if the system is in operation, there is a possibility that the 1070 service may be suspended if operation monitoring and the activities 1071 of the operator in charge of work are hindered. For example, there 1072 is a possibility that business would be suspended due to various 1073 factors such as periodic inspection of power supply facilities at 1074 operational sites, disruption of transportation by disaster, strikes, 1075 and obstruction of building access by protest activities and rush of 1076 reporters. There are also risks that many personnel cannot operate 1077 due to the same reasons, such as using the same transportation 1078 method, participating in the same event, or traffic accident or food 1079 poisoning. 1081 6.2.3.4. Regulatory risks 1083 In countries where the cryptoassets custodian is defined by law and 1084 should be licensed or registered, operations may be suspended by 1085 order of business improvement, operation suspends, deletion of 1086 license or registration issued by the authority. 1088 6.3. Risks from external factors 1090 Even if a cryptoassets custodian performs its operation 1091 appropriately, the cryptoassets custodian could not continue the 1092 service or might not execute transactions when encountering attack to 1093 the blockchain network and/or the network infrastructure connecting 1094 each node. 1096 6.3.1. Risks related to the Internet, Web PKI, and users environment 1098 6.3.1.1. Attack to Internet routing and DNS 1100 Attackers can lower the reachability to cryptoassets custodians, lure 1101 a user into the fake cryptoassets custodian, or fork deliberately by 1102 preventing the synchronization of the blockchain, through the 1103 intervention in routing or DNS, such as BGP hijacking. These methods 1104 might be used by not only malicious attackers, ISPs acting 1105 governments order. 1107 6.3.1.2. Attack to Web PKI 1109 Most cryptoassets custodians provide their services on the Web and 1110 use TLS and server certificates for authenticity and confidentiality 1111 of their website. When the certification authority issuing their 1112 certificates encounter an attack, it yields to enable to spoofing the 1113 cryptoassets custodians' website. When the certificate is revoked, 1114 the cryptoassets custodian might not be able to provide own service. 1116 6.3.1.3. Attack to messaging systems 1118 Attackers can swindle or block the e-mail and SMS using for 1119 delivering One-Time Password, through the intervention in messaging 1120 systems such as SMS or e-mail. When a users message is swindled, 1121 attackers can log in as the spoofed user or reset the password. 1123 6.3.1.4. Risks related to users environment infection 1125 When a user's environment such as PC and smartphone is infected by 1126 malware, any secrets such as credentials in the environment might be 1127 swindled. 1129 6.3.2. Risks related to cryptocurrency blockchain 1131 6.3.2.1. Split or fork of blockchain 1133 A distributed ledger might be forked by specification changes without 1134 consensus in the developers community. There are two cases around 1135 the fork; one is that the transaction before the fork is executed and 1136 recorded in both ledgers after the fork, another one is that the 1137 transaction before the fork is executed and recorded in only one 1138 ledger. 1140 6.3.2.2. Blockchain Re-organization caused by 51% attack or selfish 1141 mining 1143 When a block which is committed in the past is discarded, the 1144 transaction included in the discarded block might be rolled back. 1145 The transaction included in the discarded block is disabled, and 1146 cryptoassets or fiat money paid in compensation for the transaction 1147 might be swindled. 1149 6.3.2.3. Compromising cryptographic algorithm and hash function 1151 Improvement of performance of computing power and the discovery of 1152 effective attack might cause being compromisation of the 1153 cryptographic algorithm and hash function. 1155 6.3.2.4. Inadequate blockchain specification and implementation 1157 In the cryptoassets Lisk, there were implementations in which the 1158 timestamp value of the transaction allowed implementation of 1159 numerical value input in a range not permitted by the internal 1160 database so that each node could not process the transaction and 1161 block generation stopped[LISK-ISSUE_2088]. This issue was fixed 1162 within several hours after the problem occurred and the node updated 1163 the client software, and the network was sequentially recovered. 1165 However, the transactions could not be processed in the blockchain 1166 for a certain period. 1168 There are cases that token value collapses due to inadequate 1169 implementations of smart contract. In Beautychain Token (BEC) of 1170 ERC20 token issued on Ethereum, there is a vulnerability that causes 1171 overflow in the smart contract, so there is an attack which derives 1172 greatly exceeded tokens over the upper limit, then the worth of BEC 1173 was collapsed. [CVE-2018-10299] 1175 6.3.2.5. Rapid changes in the hashrate 1177 When the hash rate increases or decreases rapidly, it might take a 1178 very long time for generating blocks using the remaining node. 1180 6.3.3. Risks from external reputation 1182 6.3.3.1. Bank account frozen 1184 Banks might freeze an account of cryptoassets custodians operation, 1185 by the guidance of regulatory as a countermeasure for AML/CFT, or by 1186 some accidents/incidents. This freeze results in a suspending a 1187 deposit/withdraw operation of clients fiat assets. 1189 6.3.3.2. Address of cryptocurency 1191 As countermeasures for AML/CFT, other cryptoassets custodian Y might 1192 assess whether the destination address of cryptoassets custodian X 1193 have a high deal risk when a user of Y transfers some assets to the 1194 address of X. If an address of X is blacklisted, the transaction 1195 between X and Y might not be executed smoothly. 1197 Since criminals often transfer the stolen "cryptoassets" to 1198 unmalicious third party's address for disrupting investigation, the 1199 address might be involuntarily categorized as high-risk. 1201 6.3.3.3. Filtering or blocking website 1203 Users might not be able to access cryptoassets custodian when its URL 1204 is filtered out by network operators or is blocked by ISPs. When a 1205 cryptoassets custodian's website is recognized as used for malware 1206 distribution, its URL might not be appeared in search results or not 1207 be able to browse in the browser. 1209 6.3.3.4. Email 1211 Most mail servers provide a filtering service or a classifying 1212 service based on reputation, as countermeasures for spam mail. If 1213 the e-mail from the cryptoassets custodian is recognized as spam 1214 mail, the custodian might not be able to contact the user. 1216 6.3.3.5. Appraisal of a smartphone application 1218 Application delivery platform might limit applications from handling 1219 cryptoassets. When the application provided by a cryptoassets 1220 custodian could not be approved by the platforms, a user cannot 1221 download the application for access to the custodian, and cannot use 1222 the services. 1224 6.3.3.6. ID theft 1226 There is some case where the attacker acts malicious instruction 1227 spoofing as a user, for example: - list based attack, - theft of ID, 1228 password or other credentials, by a malware infection, and - theft of 1229 API access token. 1231 The distinctive purposes of spoofing are: - theft of fiat currency or 1232 cryptoassets by unauthorized withdrawals, - money laundering by 1233 cashing cryptoassets with an account in the name of other people, and 1234 - profit shifting by market manipulation by unauthorized buy and sell 1235 cryptoassets. 1237 7. Considerations of security controls on Cryptoassets Custodians 1239 7.1. General 1241 Below is a basis of security controls about risks written in 1242 Section 6. 1244 To promote understanding and coverage, all security controls in this 1245 chapter are followed by below: [ISO.27001_2013] , [ISO.27002_2013]. 1246 There are some specific considerations for Cryptoassets Custodians to 1247 follow ISOs. Especially, the organization shall consider for strong 1248 controls to manage signature keys for cryptoassets backed by assets. 1250 Other security controls are expected to be referred to similar 1251 operations by the financial sector. Security controls should be 1252 included concrete content from results of risk analysis and 1253 vulnerability diagnosis. Threats of cybersecurity are changing, 1254 reviews of security controls according to situations are important. 1255 Articles below are expected to describe contents by references and 1256 completion of description. 1258 7.2. Basis for consideration about security management 1260 There are some standards of requirement for information security, 1261 [ISO.27001_2013] and [ISO.27002_2013]. Cryptoassets Custodians shall 1262 refer the requirement or guidance of these standards and consider 1263 security controls needed and shall establish, implement, maintain and 1264 continually improve security management. Cryptoassets Custodians has 1265 data of customers asset, self asset, customer information, signature 1266 keys. Those shall be protected from leakage, loss, tampering, and 1267 misuse. Cryptoassets Custodians shall consider about risks of lost 1268 assets by foreign factors such as blockchains or network, suspension 1269 of system, and shall act properly. Cryptoassets Custodians shall 1270 mainly consider about security management described below: 1272 * Interested parties (from "4. Context of organization", 1273 [ISO.27001_2013]) To protect assets of cryptoassets custodian's 1274 customer. Division of responsibility between outsourced and 1275 cryptoassets custodians such as management of signature keys for 1276 cryptoassets. Impact of business such as money laundering shall 1277 be considered from another viewpoint. 1279 * Policy (from "5. Leadership", [ISO.27001_2013]) Cryptoassets 1280 custodians shall establish an information security policy that 1281 includes information security objectives and controls. 1282 Information security policy shall be disclosed so that customers 1283 can browse. 1285 * Continual improvement and risk assessment (from "6. Planning", 1286 "8. Operation", "9. Performance evaluation", and 1287 "10.Improvement", [ISO.27001_2013]) As described in Section 6.3.2, 1288 numbers of cryptoassets have been developed and its speed of 1289 evolving is rapid, Cryptoassets Custodians shall monitor security 1290 risks about cryptoassets in addition to information security 1291 management applied in general. Cryptoassets Custodians shall 1292 review and improve security controls according to the situation. 1294 7.3. Considerations about security controls on Cryptoassets custodians 1296 Cryptoassets Custodians shall determine information security 1297 objectives and controls from the viewpoint listed below: 1299 * Risk treatment options to prevent from loss, steal, leakage, 1300 misuse of secret keys used for cryptoassets, customer data, and 1301 customer asset. 1303 * Compliance with business 1305 * Compliance with legal and contractual requirements 1306 There are some considerations described in Section 7.2 about security 1307 controls based on system risks at Cryptoassets Custodians. There is 1308 a guidance for security controls as [ISO.27002_2013], Cryptoassets 1309 Custodians shall refer it to design and / or identify security 1310 controls. Section 7.3.1 to Section 7.3.13 below are followed to 1311 [ISO.27002_2013] and describe items to be especially noted in the 1312 virtual currency exchange system. 1314 7.3.1. Information security policies 1316 Information security policies shall be defined to follow Section 5 on 1317 [ISO.27002_2013]. Information security objectives on Cryptoassets 1318 Custodians shall include conservation of customer's asset, 1319 requirements of the business, compliance with legal and contractual 1320 requirements, social responsibilities. Information security policies 1321 shall contain policies about access controls ( on Section 7.3.5 ), 1322 cryptographic controls ( on Section 7.3.6 ), operations security ( on 1323 Section 7.3.8 ), and communications security ( on Section 7.3.9 ) . 1325 7.3.2. Organization of information security 1327 Cryptoassets custodians shall follow "6. Organization of information 1328 security" on [ISO.27002_2013], and shall establish a management 1329 framework to implement and operate information security. 1330 Cryptoassets custodians shall consider about threats such as an 1331 illegal acquisition of signature keys or illegal creation of 1332 transaction carefully. Segregation of duties shall be fully examined 1333 to manage signature keys for signing or to permit create 1334 transactions. 1336 7.3.3. Human resource security 1338 Cryptoassets custodians shall follow section "7. Human resource 1339 security" on [ISO.27002_2013]. To examine and evaluate security 1340 controls, cryptoassets custodians shall deploy human resources with 1341 expertise not only in information security applied in general but 1342 also in cryptoassets and blockchain technology. All employees may 1343 handle assets and shall receive appropriate education and training 1344 and regular updates in organizational policies and procedures. 1346 7.3.4. Asset management 1348 Cryptoassets custodians shall follow section "8. Asset management" 1349 on [ISO.27002_2013]. Cryptoassets custodians shall contain any 1350 pieces of information to manage assets, and information and asset of 1351 the customer such as the signature key. Cryptoassets custodians 1352 shall determine controls suitable for risks to follow this section if 1353 cryptoassets custodians operate hardware wallets. To protect assets 1354 of customers, cryptoassets custodians shall separate assets into 1355 customers and custodians to follow compliances with accounting. 1357 7.3.5. Access control 1359 Cryptoassets Custodians shall follow section "9. Access Controls" on 1360 [ISO.27002_2013]. 1362 Users are separated into 2 parties; Permitted operators and 1363 administrators within outsourced, and customers. Some considerations 1364 for operators and administrators are written in Section 7.3.5.1, and 1365 for customer is written in Section 7.3.5.2 1367 7.3.5.1. Access controls for operators and administrators 1369 There are some cases for operators and administrators. 1371 * Operators and administrators for custodians system. They will 1372 command to create keys or to transfer funds by software or 1373 terminal. 1375 * Administrators to maintain hardware, OS, databases, and 1376 middleware. 1378 Management measures of signature keys such as activate, backup, 1379 restore are described on Section 7.3.6. Cryptoassets custodian shall 1380 be carried out to assign authority to operate properly and shall set 1381 access control. Access controls shall be include authorize and 1382 permit to connect custodians system from remote, authorize for 1383 external service if using as functions for cryptoasset custodians, 1384 authorize as a user for OS and databases, permit to enter and leave 1385 facilities systems or terminals installed. There are some factors to 1386 permit access: Only office hours or predetermined hours, Only IP 1387 addresses assigned for specific terminals, Confirm by credentials to 1388 connect from operators or terminals predetermined. Cryptoassets 1389 custodians shall consider for access control policies by roles or 1390 authorities of operators and administrators for each system. Access 1391 control shall be set the minimum to run functions or software 1392 permitted for operators or administrators, not only for applications. 1394 Any damage may be happened by miss or injustice operations on 1395 transferring assets or managing signature keys as described 1396 Section 6.2. To deter these threats, Confirmation of or approval by 1397 multiple operators or multiple administrators shall be needed on 1398 important operations such as transferring assets and operations for 1399 the signature key. Cryptoassets custodians shall not concentrate 1400 duties for one operator or administrator, decentralize of duties for 1401 multiple operators or administrators shall be needed. 1403 7.3.5.2. Access control for customers (user authentication / API) 1405 * Strict personal identification on setup account The account shall 1406 be set up by strict personal identification, and account 1407 information shall be sent to the person itself. For example, 1408 personal identification shall be operated by an identification 1409 document issued by the public organization and shall be sent a 1410 letter to the address without forwarding. Personal identification 1411 shall be carried out in accordance with relevant laws, 1412 regulations, treaty such as FATF. Replacement of pictures on an 1413 identification document or falsification of attribute information 1414 is typical treats for personal identification. In order to 1415 operate personal identification strictly, it shall be carried out 1416 to verify by software or visual check and verify by an electric 1417 method such as signature that is hard to falsification. 1419 * Managing credential and multi-factor authentication For user 1420 authentication, it is expected to prevent from spoofing and 1421 internal injustice by installing risk-based authentication on not 1422 normal access ( such as a characteristic of terminal or route, and 1423 different time slot from usual ) and multi factor authentication 1424 on spoofing by leakage of single credential. It is NOT 1425 recommended to deliver one-time-password by unprotected 1426 transmission line as email because there is a risk of 1427 impersonation or fraud on the transfer route. Confirming 1428 telephone number by SMS was valid for verifying owner and 1429 reachability, but that has been RESTRICTED by NIST, so personal 1430 authentication technology such as possession identification and 1431 transaction authentication technology should be applied. SMS may 1432 be one factor used to recovery account, but not measure to confirm 1433 the existence and authenticate. 1435 * Multi-factor authentication, risk-based authentication It shall be 1436 carried out to register customer and set access controls strictly 1437 to avoid defraud customer funds, changing to fiat and money 1438 laundering by spoofing customers. 1440 * Confirmation of intention according to the risk of operation To be 1441 consistent with the convenience of customers and safety of 1442 service, It shall be considered to make a different level to 1443 authenticate by risks of customer's operation. For example, low- 1444 risk operations such as display balance of account or details of 1445 trade may be allowed by single-factor authentication, but update 1446 transactions such as trading coins or changing address or account 1447 shall be authenticated by an additional factor. In addition, 1448 operations it may cause damages such as output coin or order of 1449 fiat transaction shall be ordered to confirm by additional 1450 authenticate or to confirm intention by an operator. 1452 * Data preservation on deleting an account Cryptoassets custodians 1453 shall implement system be able to rollback after erasing for a 1454 certain period if customer stated spoofed or unauthorized access. 1455 Cryptoassets custodians shall delete the account if requested from 1456 a customer, but they also shall consider about risks that attacker 1457 spoofed to customer requests to delete the account. 1459 * Signature key preservation on discontinue addresses Signature keys 1460 linked to an account shall not be deleted even if the address of 1461 cryptoassets has no value. On a prediction for the general 1462 cryptoassets customer is allowed to send assets for any addresses 1463 and not technically prevented to send, signature keys for wallet 1464 stopped to use shall be taken back up for reuse because the 1465 possibility of receive coins to the address exists. 1467 * Consideration for supplying APIs To set access control for 1468 operations by a customer, it shall be considered about not only 1469 operations of dialogue operations on the web but also APIs 1470 connecting from the application by smartphone and from external 1471 systems. For providing APIs, It shall be implemented to consider 1472 cases that are difficult to get explicit approval from customer. 1473 It shall comply with best practices shared in the industry based 1474 on the attack risk peculiar to API. For reference, it may be 1475 followed to Financial API by OpenID Foundation. 1477 7.3.6. Security controls on signature keys 1479 It SHALL conform to Section 10 "Cipher" of [ISO.27002_2013]. 1481 Particularly, some security controls for the signature key, an issue 1482 specific to cryptoassets custodians, are closely related to the 1483 controls in other sub-sections in this section (e.g., Section 7.3.5). 1485 Amount of cryptoassets in Hot Wallet MUST be limited to a minimum 1486 amount and isolate their remain assets to another secure place, e.g., 1487 Cold wallet. The minimum amount means the amount which can be 1488 temporarily paid within the time it takes to withdraw the assets from 1489 the secure place. Custodian can be refunded to the customers from 1490 the remain assets even if the assets in Hot Wallet leaks. 1492 Custodians MUST choose an appropriate cryptographic technology that 1493 has been evaluated its security by the third party in accordance with 1494 the purpose of use, as with general information systems. Also, they 1495 MUST decide the life cycle of a signature key and MUST implement and 1496 operate appropriate controls. 1498 7.3.6.1. Basics of Signature Key Management 1500 In general, followings are required in the management of private keys 1501 including signature keys. 1503 * They should be isolated from other informational assets. Rigorous 1504 access control is mandatory. 1506 * Limit the number of access to signature keys as minimum as 1507 possible. 1509 * Be prepared for unintentional lost of signature keys. 1511 Followings are three basic security control to realize above. 1512 Additional security controls specific to crypto assets custodians are 1513 described in and after sub-sections Section 7.3.6.2. 1515 1. State management of signature keys As described in Figure 2, a 1516 signature key has one of the multiple states generally, and it 1517 may be an active or inactive state in its operation. The 1518 signature key MUST be in an active state when it is used for 1519 signing (or decryption). It is recommended to enforce to input 1520 some secret information to activate from the inactive signature 1521 key. This makes keeping the inactive signature key away from 1522 abuse if the adversary does not have the secret information. 1523 This method ensures also the security of the signature key 1524 against leakage and lost. It is also recommended to minimize the 1525 term of activation to limit the risk of abuse as minimum as 1526 possible. Unnecessary activation of the signature key increases 1527 the risk of abuse, leakage, and theft, though keeping the 1528 activation state is efficient from a business viewpoint. On the 1529 other hand, frequent activation/inactivation may give impact to 1530 business efficiency. It is important to consider the trade-off 1531 between the risk and business efficiency and provide clear key 1532 management policy to customers. 1534 2. Administrator role separation and two-person rule It is a 1535 fundamental form of operation of a critical business process 1536 which uses the signature key to perform cryptographic operations 1537 by multiple parties to prevent internal frauds and errors. For 1538 example, by setting separated privilege on digitally signing and 1539 approval to go into the area of signing operation, it becomes 1540 difficult for the single adversary to give a malicious digital 1541 signature without known by the third party. Additionally, the 1542 enforcement of the two-person rule is effective security control 1543 to internal frauds and misoperations. 1545 3. Backup of a signature key Lost of the signature key makes signing 1546 operations (by using the key) impossible any more. Thus backup 1547 of the signature key is an important security control. Since 1548 lost of the signature key makes signing operations impossible any 1549 more, backup of the signature key is an important security 1550 control. On the other hand, risks of leakage and theft of backup 1551 keys MUST be considered. It is needed to inactivate the backup 1552 keys. Additionally, monitoring the blockchain whether to perform 1553 the outgoing-coin from that address to detect the inappropriate 1554 backup and the illegal-use of little-used address. 1556 7.3.6.2. Offline Key Management 1558 There is a type of offline key management (as known as "cold wallet") 1559 which isolates signature keys from the system network to prevent 1560 leakage and theft caused by the intrusion. 1562 (Artwork only available as svg: No external link available, see 1563 draft-vcgtf-crypto-assets-security-considerations-07.html for 1564 artwork.) 1566 Figure 4: Example of offline signature key management 1568 In this case, it REQUIREs some kind of offline operations to make the 1569 system use the signature key. 1571 Examples are a) it requires to move a signature key from the vault 1572 and to connect to the online system, b) input/output between online 1573 system and offline (key management) system does perform through a 1574 kind of storage, such a USB Flash Drive. 1576 If there is not an explicit approval process for the signature key 1577 used in the offline operation, anyone cannot stop the malicious 1578 transaction. That is, for achieving this solution can prevent abuse, 1579 loss, and theft of signature keys, an explicit approval process is 1580 needed for this solution. 1582 7.3.6.3. Privilege separation of signature keys (Authorization process) 1584 Both privilege separation and two-person control of signature key 1585 management are effective as shown in Section 7.3.6. In addition, 1586 there is multi-signature as a typical scheme for 1587 blockchain[BIP-0010][BIP-0011]. Multi-signature REQUIREs an 1588 authorization process with multi-stakeholders, and it is achieved by 1589 signing with the signature keys managed by each stakeholder. Each 1590 stakeholder MUST verify other signatures technically if exists, and 1591 MUST validate the practical consistency of the transaction. 1593 Authorization process with multiple stakeholders can expect for a 1594 general countermeasure for malicious generation of a transaction. 1595 Note, however, that security controls for the leakage and/or loss of 1596 the signature key are still needed. 1598 Since a multi-signature scheme is provided by software, its logic and 1599 implementations are varied with some blockchain. e.g., multi- 1600 signature in Ethereum is implemented on smart contract, so that there 1601 are various implementations with each wallet software. Also, some 1602 blockchains might not support multi-signature, therefore some 1603 cryptoassets could not adopt multi-signature. 1605 Also, there is another similar scheme "Secret Sharing Scheme" which 1606 is applicable to privilege separation. This is a management 1607 technology in a distributed environment which has divided secret 1608 respectively, and one of the countermeasures for leakage and/or lost 1609 of signature key. However, this scheme is rather a technology for 1610 single stakeholder with multi-location operation than multi- 1611 stakeholders, because it REQUIREs a validation scheme separately for 1612 the transaction to each stakeholder and management of the divided 1613 secret is rather depend to implementation than the signature key. 1615 7.3.6.4. Backup for Signature Key 1617 Backup is the most fundamental and effective measure against lost of 1618 signature key. On the other hand, there are risks of leakage and 1619 loss of the backup device. 1621 These risks depend on the kind backup device, thus security controls 1622 on such devices MUST be considered independently. Followings 1623 describe typical backup devices and leakage/theft risks associated 1624 with them. 1626 * Cloning to the tamper-resistant cryptographic key management 1627 device If a signature key is managed by a tamper-resistant key 1628 management device (device X) and X has cloning function, cloning 1629 the key to another device Y is the most secure way to back up the 1630 key, where the cloning function is the technique to copy the key 1631 with keeping confidentiality to other devices than X and Y 1632 // For example, cloning via PC does not meet this requirement when 1633 // the signature key is read into memory on the PC in the cloning. 1635 * Backup to storage for digital data Here, it is assumed to backup 1636 keys to storage like USB memory and DVD. There are two types of 1637 operations; one is backup data is stored in movable devices in an 1638 offline manner, the other is backup data is stored in an online 1639 accessible manner. If the device is movable, the possibility of 1640 steal and lost increases, thus the device MUST be kept in a 1641 cabinet or a vault with the key, and the access control to such 1642 cabinet/vault MUST be restricted. Of the backup storage is 1643 online, risks of leakage and theft MUST be assumed as same as the 1644 key management function implementation inside the cryptoassets 1645 custodian. In general, the same security control is recommended 1646 to such backup storage. If there is some additional operation, 1647 for example, the backup device is inactivated except for the time 1648 of restore, the security control may be modified with considering 1649 the operating environment. When it is not avoided the raw key 1650 data is outside of the key management function implementation, the 1651 custodian MUST deal with the problem of remained magnetics. 1653 * Backup to paper There is a way to backup keys in an offline 1654 manner, to print them to papers as a QR code or other machine 1655 readable ways. It is movable than storage for digital data and 1656 easy to identify. There remains some risk of leakage and theft by 1657 taking a photo by smartphone and so on. 1659 * Redundant with Sharing secret scheme Dividing of signature key to 1660 multiple parts, then managing them by multiple isolated systems is 1661 an effective measure to protect the keys against leakage and 1662 theft. This document does not recommend a specific technique but 1663 RECOMMENDs to implement this control based on a certain level of 1664 security evaluation like a secret sharing scheme. In that case, 1665 secure coding and mounting penetration test are REQUIRED to 1666 eliminate the implementation vulnerabilities. This method is also 1667 effective for backup devices. 1669 7.3.6.5. Procurement of hardware wallet 1671 When introducing a wallet, it is RECOMMEND to use a product whose 1672 technical security is guaranteed like HSM which is originally used 1673 for existing PKI service etc. However, some products may not be 1674 applicable currently because they often do not support a kind of 1675 cryptographic algorithm used by crypto assets. Therefore, if 1676 introducing a wallet, it is RECOMMEND to operate in mind the 1677 following points with accepting the technical insufficiency: 1679 * MUST not use hardware obtained through the untrusted procurement 1680 route. 1682 * MUST apply the latest firmware and patches provided by the 1683 manufacturer. 1685 * Initialization and key generation MUST do themselves, SHOULD NOT 1686 use default settings without careful considerations. 1688 * MUST consider trustworthy of software instructing a sign to 1689 hardware wallet, especially whether it supports multi-signature or 1690 signing at the offline environment. 1692 Additionally, when custodian uses only hardware wallets in the 1693 marketplace, they MUST manage it according to section Section 7.3.4. 1695 On the other hand, hardware wallets MUST be subject to the third- 1696 party or independent certification scheme for security. If 1697 introducing a software wallet from outside, it MUST consider the 1698 potentiality of containing malicious code, vulnerability, and bugs. 1700 7.3.7. Physical and environmental security 1702 Cryptoassets custodians system MUST follow section "11. Physical and 1703 environmental security" on [ISO.27002_2013]. 1705 Cryptoassets custodians system MUST consider strict physical security 1706 protections for the following elements. 1708 * Media containing a signature key. (Signature key management shown 1709 in Figure 1) 1711 * Media containing a signature key for cold wallet environment. 1712 (Signature key management for offline management shown in 1713 Figure 4.) 1715 * Media containing a backup data of signature key 1717 If the signature key mentioned above is stored in the deactivated 1718 state, and also key encryption key to activate the signature key is 1719 controlled separately, the media containing the key encryption key 1720 MUST be strictly managed. 1722 The security control to these signature key MUST be separated from 1723 the security control of the crypto assets custodian system. In 1724 addition to this control, access to facilities and environments which 1725 store media containing a signature key or information required to 1726 operate the signature key MUST be restricted. (See: Section 7.3.6) 1728 Furthermore, countermeasures to loss or theft for the operational 1729 device MUST be taken place if the administration or operation is 1730 executed from a remote place such as out of a facility. 1732 7.3.8. Operations security 1734 Crypto Assets Custodian systems MUST follow section "12. Operations 1735 security" on [ISO.27002_2013]. In addition to the standard, 1736 cryptoassets custodian systems SHALL comply with the security 1737 controls mentioned following sections. 1739 7.3.8.1. Protections from malicious software (Related to ISO.27002:2013 1740 12.2) 1742 Detection and recovery measures of malware MUST be appropriately 1743 taken place according to configurations, the environment of 1744 cryptoassets custodian systems and confidentiality and importance of 1745 information handled in the systems. 1747 In general, one of the prevention measures for malware is applying 1748 security patches to operating systems, middlewares of cryptoassets 1749 custodian systems. However, those patches MUST be applied upon 1750 sufficient confirmation based on the importance and urgency of a 1751 patch. Moreover, testing and deployment procedure of security patch 1752 MUST be considered beforehand just in case attacks against the 1753 vulnerability have already confirmed. 1755 7.3.8.2. Backup (Related to ISO.27002:2013 12.3) 1757 Upon making a backup of systems, strict security controls to 1758 important data which suffered severe damage by leakages such as the 1759 signature key or master seed MUST be applied same as data subject to 1760 backup (e.g., an appropriate selection for storage, and enforcement 1761 of strict access controls.) Security controls such as distributed 1762 storage mentioned in Section 7.3.6), proper privilege separation on 1763 backup and restore between operators and people making an 1764 authorization, and operation with multiple parties are also 1765 important. 1767 7.3.8.3. Logging and monitoring (Related to ISO.27002:2013 12.4) 1769 Crypto asset custodians systems MUST obtain/monitor/record logs 1770 properly (not limited to but include following logs). 1772 * Logs on the environment where the cryptoassets custodian system 1773 Collecting and monitoring of event log outputted from the system 1774 components such as middleware, operating systems, and computers 1775 detects an abnormal state of environment where the system runs. 1776 Collected logs are used to investigate a cause in the case of the 1777 incident. 1779 * Logs on the processing of components of crypto assets custodians 1780 system Collecting and monitoring of the processing logs from each 1781 component detects an abnormal state of crypto assets custodians 1782 system. Collecting proper logs are used as a proof of proper 1783 processing inside the crypto assets custodians system, and also 1784 used to investigate a cause in a case of the incident. 1786 * Access log of signature key Information such as date, a source 1787 terminal, an operator(not a role but information to identify an 1788 operator) MUST be obtained and recorded in a case of operations 1789 such as activation and deactivation of the signature key, access 1790 to the activated signature key and backup/restore. Those records 1791 MUST be validated against the records such as operational 1792 procedures, operating hours, on a periodical inspection such as 1793 weekly inspection. Moreover, in a case where the signature key is 1794 managed online, operational log such as the creation of a 1795 transaction signature by operator MUST be recorded and validated 1796 as well. 1798 * Operational Log of a wallet managed by custodians Logs on 1799 remittance MUST be monitored real-time against the attempt of 1800 outgoing coin transfer in a case where the signature key and 1801 backup are unexpectedly leaked. In a case where an unexpected 1802 remittance has occurred in one of the wallets, monitoring logs 1803 help timely detecting the incidents, suspending all signing 1804 operations, rechecking on other existing wallets, and migrating to 1805 other wallets using a different signature key. 1807 * Access log of administration remote terminal If a remote access to 1808 cryptoassets custodian system is permitted, audit information such 1809 as date, source IP address, terminal information(e.g. terminal ID, 1810 latest result of security evaluation if it's possible) and 1811 destination IP address (or hostname) MUST be obtained and recorded 1812 for auditing which checks the accesses are from/in authorized 1813 range. 1815 * Traffic log between the inside and the outside (e.g., the 1816 Internet) As mentioned in Section 7.3.9.1, Inbound traffic to 1817 cryotoassets custodian systems such as traffic from the Internet 1818 MUST be restricted to a permitted external network or permitted 1819 protocol. Inbound traffic from disallowed network and traffic 1820 using disallowed protocol are denied at the firewall and other 1821 middleboxes. Logs from that equipment are effective to protect 1822 customers from malicious access in terms of not only cryptoassets 1823 custodian system but also the information security. Usually, 1824 outbound traffic from protected assets such as cryptoassets 1825 custodian systems to the Internet and other systems is not a 1826 subject to logging. However, those logs are useful in cases such 1827 as investigations on incidents (e.g., malicious usage of the 1828 signature key, theft of signature key) and detection of the 1829 incident, so entire traffic or network flow are RECOMMENDED to be 1830 acquired according to protocols/destinations. 1832 * Customers access log Customers access log MUST be obtained since 1833 those logs are used to detect malicious login or request. Also, 1834 those logs are used as evidence in a case of incidents. In a case 1835 of malicious login, custodians MUST notify its customer. 1837 - Provide information about the malicious activity to customers 1838 Providing a feature to allow a customer to confirm login 1839 history, source IP address, region, and terminal information, 1840 and login notification by a push-notification or an e-mail are 1841 effective to detect malicious access after the incident. 1842 Feature protecting an account and alerting to a user in cases 1843 when detecting login from unknown source address or terminal, 1844 or detecting consecutive login to multiple accounts from the 1845 same source IP address, are effective to protect a user from 1846 malicious access. 1848 * Images/videos recorded by a surveillance camera and entry/exit 1849 records Storing images/videos recorded by the surveillance camera 1850 and entry/exit records for proper period enables validating if 1851 physical safety control measures work properly after the incident. 1853 Detecting a malicious process execution (e.g., malware), malicious 1854 access, an abnormal state of cryptoassets custodians system by 1855 monitoring logs mentioned above comprehensively is important. 1856 Moreover, storing this evidence is important to prevent internal 1857 fraud and exonerate person involved from the charge. Security 1858 Operation Center (SOC) may help to monitor the system. Outsourcing 1859 to trusted operators about detection and notification of threats in 1860 the operation of SOC may be helpful. 1862 7.3.9. Communications security 1864 Cryptoassets custodians system MUST follow section "13. 1865 Communications security" on [ISO.27002_2013]. 1867 Since assets are managed in a state accessible from the Internet on 1868 cryptoassets custodians system, preventive measures, detection 1869 measures, countermeasures and recovery measures as measures to 1870 prevent information leakage, MUST be considered according to the 1871 risk. 1873 7.3.9.1. Network security management (Related to ISO.27002:2013 clause 1874 13.1.1) 1876 As same as security control measures to general systems, measures 1877 such as a definition of a boundary to the external network, 1878 restriction of connection to a network system(e.g., firewall), stop 1879 unnecessary services or close unnecessary ports, obtaining and 1880 monitoring logs and malicious access detection MUST be considered and 1881 performed. 1883 For logs, logs of internal systems MUST be monitored to detect 1884 internal malicious access, as well as monitoring of boundary to the 1885 external network. (See: Section 7.3.8.3) 1887 Secure communication with proper mutual authentication such as 1888 TLS(Transport Layer Security) MUST be used to protect from attacks to 1889 communication between modules such as eavesdropping and manipulation 1890 in a case where modules of cryptoassets custodians systems are 1891 remotely located. 1893 7.3.9.2. Network segmentation (Related to ISO.27002:2013 13.1.3) 1895 It is important to limit a connection between cryptoassets custodians 1896 systems and other systems/the Internet as minimum as possible to 1897 reduce the risk of exposing against attacks through a network. 1898 Measures as follow such as network segmentation and limitation to 1899 connection MUST be considered. 1901 * Network isolation between custodians systems and other information 1902 systems 1904 - Objectives: Preventing a connection to custodians systems 1905 through information systems used in daily operations, which has 1906 been compromised due to malware infections caused by external 1907 attacks such as targeted attack. 1909 - Countermeasures: Isolate a network between information systems 1910 used in daily operations and custodians system by segmentation 1911 of network or limiting access. 1913 * Network isolation at the boundary to the Internet 1915 - Objective: Preventing access to critical information such as a 1916 signature key from attack through the Internet by minimizing 1917 and isolating modules which connect to the Internet. 1919 - Countermeasures: Features which connects external services on 1920 the Internet to achieve the functionality of custodians system, 1921 transmit transactions or obtain blockchain data MUST be 1922 packaged as a module as minimum as possible or be isolated from 1923 other systems such as locating on DMZ. Moreover, if modules 1924 are connecting to external services, access controls to those 1925 services MUST be adequately performed. 1927 * Limitation on a terminal used in custodians system administration 1929 - Objective: Preventing a malicious operation due to a hijacking 1930 of terminal used in custodians system administration. 1932 - Countermeasures: Limiting a terminal which can connect to 1933 custodians system, such as a terminal to manage a custodians 1934 system administration function and a terminal running an 1935 administrative tool to order operation to custodians system. 1937 7.3.9.3. System acquisition, development and maintenance 1939 Cryptoassets custodians system MUST follow section "14. System 1940 acquisition, development, and maintenance" on [ISO.27002_2013]. 1942 Cryptoassets handled by cryptoassets custodians ranges from high 1943 liquidity cryptoassets dealt with by multiple custodians to emerging 1944 cryptoassets. It is important to reduce a risk regarding system 1945 acquisition, development and maintenance in addition to 1946 [ISO.27002_2013] as characteristics of blockchain network used by 1947 those cryptoassets varies. For example, the following 1948 countermeasures are effective. 1950 * Software development method Secure software development method 1951 such as secure coding and code review MUST be used in the software 1952 development of the custodian system. Code review not only with 1953 the development team but also with an operational team is 1954 effective to detect a vulnerability from the viewpoint of 1955 operation. 1957 * Penetration test Conducting a penetration test helps to detect a 1958 known vulnerability at systems and results in obviating the 1959 attacking risk by the attacker in advance. 1961 * Integration test with blockchain network Test MUST be performed 1962 not only with the test network of blockchain but also with the 1963 production network of the blockchain. Risk assessment MUST be 1964 taken with an understanding of the limitation of test on the 1965 production network such as high-load test. 1967 * Privilege separation on the operation Privilege separation such as 1968 limiting code reviewed software deployment to the production 1969 environment to the system operating team is effective to prevent 1970 tampering attacks from internal. 1972 * Prohibiting using default (factory-configured) values Any factory- 1973 configured authentication information such as password MUST NOT be 1974 used regardless of hardware/software, development environment or 1975 production environment. 1977 7.3.10. Supplier relationships 1979 Cryptoassets custodians system MUST follow section "15. Supplier 1980 relationships" on [ISO.27002_2013]. 1982 Outsourcing wallet-related services may be a reasonable choice in a 1983 case technical security of those services has been secured. 1985 Administrative measures according to [ISO.27002_2013] MUST be taken 1986 in terms of outsourcing contractors or security controls of cloud 1987 service providers in cases where signature key in multi-signature is 1988 delegated to contractors or custodians system is implemented on cloud 1989 services. 1991 7.3.11. Information security incident management 1993 Cryptoassets custodians system MUST follow section "16. Information 1994 security incident management" on [ISO.27002_2013]. 1996 Since cyber attacks got complex, cyber security incidents 1997 unprecedented in the past could occur, especially in cryptoassets 1998 custodians. In addition to security control measures as a 1999 preparation to expected threat in advance, Emergency response 2000 framework MUST be prepared in a case of incidents caused by an 2001 unknown threat. For example, the establishment of internal 2002 CSIRT(Computer Security Incident Response Team) and building a 2003 relationship with external organizations. 2005 7.3.12. Information security aspect of business continuity management 2007 Cryptoassets custodians system MUST follow section "17. Information 2008 security aspect of business continuity management" on 2009 [ISO.27002_2013]. 2011 Requirements, Processes, Procedures and control measures to secure 2012 information security for the cryptoassets custodian in a case of the 2013 severe situation(such as disaster or crisis) MUST be established, 2014 documented, performed and maintained. In this case, administrative 2015 measures in a case where countermeasures have performed or in a 2016 period of a severe situation MUST be verified periodically. 2017 Moreover, operators MUST consider to shut down the system 2018 situationally. 2020 * In a case where facilities (including facilities used as an 2021 office) are unavailable 2023 - Power outage 2025 - Damages of building 2027 - An act of nature (e.g., earthquakes, fires (including sprayed 2028 water for neighborhoods fire), water outage, flood) 2030 - Other reasons (e.g., facilities are unavailable, or access to 2031 the facilities are prohibited by law/regulations/authorities.) 2033 * In a case where it's difficult to continue the system 2035 - In a case of becoming difficult to continue running an 2036 emergency electric generator. 2038 - Long suspension of public transportation services, a pandemic 2039 of disease, lack of human resources by an act of nature. 2041 - Failure of a communication network 2043 - Failure of equipment 2045 - Failure of the system (regardless of reasons such as failure of 2046 a program or cyber attacks) 2048 - Loss of paper wallet or hardware wallet. 2050 - Suspension of outsourcing contractor's business 2052 - Leakage or loss of signature key 2054 * In the case of becoming difficult to continue business 2056 - Business-suspension order by law/regulations. 2058 7.3.12.1. Maintaining availability of the system 2060 Cryptoassets custodians system MUST be designed and implemented to 2061 have enough scalability and redundancy for users with consideration 2062 of a number of users, peak date/time of transactions, system response 2063 time, maintenance period/frequency and securing a human resource for 2064 operation. Moreover, consideration for increasing the capacity of 2065 the system MUST be performed in advance with enough threshold (e.g., 2066 number of transactions or memory usage during a peak period). 2068 7.3.13. Compliance 2070 Cryptoassets custodians MUST respect the guidelines or laws of the 2071 region or country. (See Appendix 3 for a country of Japan) 2073 7.4. Other cryptoassets custodians system specific issues 2075 7.4.1. Advance notice to user for maintenance 2077 Cryptoassets custodians are RECOMMENDED to publish a notice of 2078 maintenance schedule in advance in a case where periodical schedule 2079 especially service suspension is planned in a night. Also, 2080 Cryptoassets custodians are RECOMMENDED to provide information 2081 regarding the failure of the system at other FQDN/IP addresses to 2082 avert high volume traffic to the web server in addition to usual way 2083 of notice such as by e-mail or on the website, in a case of emergency 2084 maintenance. 2086 Moreover, cryptoassets custodians are RECOMMENDED to put forth an 2087 effort to minimize an affected area from a viewpoint of user 2088 protection in a case of service suspension caused by immediate issues 2089 such as attacks from external. 2091 8. Future work 2093 Discussion of distributed exchange (DEX) is currently out-of-the- 2094 scope of this document. 2096 9. Security Considerations 2098 Security Considerations are included in the main section of this 2099 document. 2101 10. IANA Considerations 2103 None. 2105 11. References 2106 11.1. Normative References 2108 [ISO.27001_2013] 2109 International Organization for Standardization, 2110 "Information technology -- Security techniques -- 2111 Information security management systems -- Requirements", 2112 ISO/IEC 27001:2013, October 2013, 2113 . 2115 [ISO.27002_2013] 2116 International Organization for Standardization, 2117 "Information technology -- Security techniques -- Code of 2118 practice for information security controls", ISO/ 2119 IEC 27002:2013, October 2013, 2120 . 2122 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2123 Requirement Levels", BCP 14, RFC 2119, 2124 DOI 10.17487/RFC2119, March 1997, 2125 . 2127 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2128 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2129 May 2017, . 2131 11.2. Informative References 2133 [BIP-0010] Reiner, A., "Multi-Sig Transaction Distribution", BIP 10, 2134 28 October 2011, 2135 . 2138 [BIP-0011] Andresen, G., "M-of-N Standard Transactions", BIP 10, 18 2139 October 2011, 2140 . 2143 [CVE-2018-10299] 2144 MITRE Corporation, "CVE-2018-10299", CVE 2018-10299, 22 2145 April 2018, . 2148 [I-D.nakajima-crypto-asset-terminology] 2149 Nakajima, H., Kusunoki, M., Hida, K., Suga, Y., and T. 2150 Hayashi, "Terminology for Cryptoassets", Work in Progress, 2151 Internet-Draft, draft-nakajima-crypto-asset-terminology- 2152 04, 2 July 2020, . 2155 [LISK-ISSUE_2088] 2156 MaciejBaj, ., "Check INT_32 range for transaction 2157 timestamps", June 2018, 2158 . 2160 Acknowledgements 2162 Thanks to Masanori Kusunoki, Yasushi Matsumoto, Natsuhiko Sakimura, 2163 Yuji Suga, Tatsuya Hayashi, Keiichi Hida, Kenichi Sugawara, Naochika 2164 Hanamura, and other members of the Security Working Group of 2165 CryptoAssets Governance Task Force (https://vcgtf.github.io). 2167 Authors' Addresses 2169 Masashi Sato 2170 SECOM Co., Ltd. Intelligent System Laboratory 2171 Shimorenjaku 8-10-16 2172 SECOM SC Center, Tokyo, Mitaka 2173 181-8528 2174 Japan 2176 Email: satomasa756@gmail.com 2178 Masaki Shimaoka 2179 SECOM Co., Ltd. Intelligent System Laboratory 2180 Shimorenjaku 8-10-16 2181 SECOM SC Center, Tokyo, Mitaka 2182 181-8528 2183 Japan 2185 Email: m-shimaoka@secom.co.jp 2187 Hirotaka Nakajima (editor) 2188 Mercari, Inc. 2189 Roppongi 6-10-1 2190 Roppongi Hills Mori Tower 18F, Tokyo, Minato 2191 106-6118 2192 Japan 2194 Email: nunnun@mercari.com