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