|
US$819.00 · In stock
Delivery: <= 6 days. True-PDF full-copy in English will be manually translated and delivered via email.
JR/T 0184-2020: (Technical specification for financial distributed ledger technology)
Status: Valid
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Standard Title (Description) | Status | PDF |
| JR/T 0184-2020 | English | 819 |
Add to Cart
|
6 days [Need to translate]
|
(Technical specification for financial distributed ledger technology)
| Valid |
JR/T 0184-2020
|
PDF similar to JR/T 0184-2020
Basic data | Standard ID | JR/T 0184-2020 (JR/T0184-2020) | | Description (Translated English) | (Technical specification for financial distributed ledger technology) | | Sector / Industry | Finance Industry Standard (Recommended) | | Classification of Chinese Standard | A11 | | Word Count Estimation | 34,399 | | Date of Issue | 2020-02-05 | | Date of Implementation | 2020-02-05 | | Regulation (derived from) | Notice of National Financial Standardization Technical Committee (2020.02.05a) | | Issuing agency(ies) | People's Bank of China | JR/T 0184-2020: (Technical specification for financial distributed ledger technology)---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order.
Financial distributed ledger technology security specification
ICS 35.240.40
A 11
JR
People's Republic of China Financial Industry Standards
Financial Distributed Ledger Technology Security Specification
2020-02-05 release
2020-02-05 Implementation
Issued by the People's Bank of China
Table of contents
Foreword...I
Introduction...II
1 Scope...1
2 Normative references...1
3 Terms and definitions...1
4 Abbreviations...6
5 Security System Framework...6
6 Basic hardware...7
6.1 Basic requirements...7
6.2 Physical Security...7
6.3 Network Security...7
7 Basic Software...8
7.1 Basic requirements...8
7.2 Ledger structure...8
7.3 Consensus module...8
7.4 Distributed networking...8
7.5 Data Storage...8
7.6 Smart Contract...8
7.7 Interface Design...9
7.8 Data Transmission...9
7.9 Time synchronization...9
7.10 Operating System...9
8 Cryptographic Algorithm...9
8.1 Basic requirements...9
8.2 Confidentiality...9
8.3 Completeness...9
8.4 Authenticity...10
8.5 Non-repudiation...10
8.6 Randomness...10
8.7 Key Management...10
9 Node Communication...10
9.1 Basic requirements...10
9.2 Node authentication...10
9.3 Communication integrity...10
9.4 Communication confidentiality...11
10 Ledger Data...11
10.1 Completeness...11
10.2 Consistency...11
10.3 Confidentiality...11
10.4 Validity...11
10.5 Ledger data redundancy...11
10.6 Access and use...11
10.7 Security Audit...11
11 Consensus Agreement...12
11.1 Basic requirements...12
11.2 Legality...12
11.3 Correctness...12
11.4 Finality...12
11.5 Consistency...12
11.6 Unforgeability...12
11.7 Availability...12
11.8 Robustness...12
11.9 Fault tolerance...13
11.10 Supervisability...13
11.11 Low Latency...13
11.12 Incentive compatibility...13
11.13 Scalability...13
12 Smart Contract...13
12.1 Basic requirements...13
12.2 Version Control...13
12.3 Access Control...13
12.4 Complexity Limitation...13
12.5 Atomicity...14
12.6 Consistency...14
12.7 Security Audit...14
12.8 Life Cycle Management...14
12.9 Attack Defense...14
12.10 Security Verification...14
13 Identity Management...14
13.1 Basic requirements...14
13.2 Identity definition...14
13.3 Identity Registration...15
13.4 Identity Verification...15
13.5 Account Management...15
13.6 Credential Lifecycle Management...16
13.7 Identity Authentication...17
13.8 Node ID Management...18
13.9 Identity renewal and revocation...18
13.10 Identity Information Security...18
13.11 Identity supervision audit requirements...19
14 Privacy protection...20
14.1 Privacy protection principles...20
14.2 Privacy protection content...20
14.3 Privacy Protection Policy...20
14.4 Privacy protection technical requirements...21
14.5 Privacy protection monitoring and auditing...22
15 Regulatory Support...22
15.1 Basic requirements...22
15.2 System Supervision...22
15.3 Information Management...22
15.4 Event handling...22
15.5 Transaction Intervention...22
15.6 Smart Contract Supervision...22
16 Operation and maintenance requirements...22
16.1 Basic requirements...23
16.2 Device Management...23
16.3 Node Monitoring...23
16.4 Node version upgrade...23
16.5 Bug fixes...23
16.6 Backup and Restore...23
16.7 Emergency plan management...24
16.8 Rights Management...24
16.9 Proposal Mechanism...24
17 Governance Mechanism...24
17.1 Basic requirements...24
17.2 Governance structure...24
17.3 Key Points of Control...25
References...27
Foreword
This standard was drafted in accordance with the rules given in GB/T 1.1-2009.
This standard was proposed by the Digital Currency Research Institute of the People's Bank of China.
This standard is under the jurisdiction of the National Financial Standardization Technical Committee (SAC/TC 180).
The organization responsible for drafting this standard. Digital Currency Research Institute of the People's Bank of China.
Participated in the drafting of this standard. Science and Technology Department of the People’s Bank of China, Industrial and Commercial Bank of China, Agricultural Bank of China, Bank of China, China Construction
Bank, China Development Bank, Ping An Bank, China Merchants Bank, Shenzhen Qianhai WeBank Co., Ltd., Zhejiang Netshang Bank Co., Ltd.
Company, Tsinghua University, Shanghai Jiaotong University, Nanjing University, Zhejiang University, China Banknote Hangzhou Blockchain Technology Research Institute, China Information and Communication Research Institute
Research Institute, CICC Guosheng Certification Co., Ltd., Bank Card Testing Center, JD Digital Technology Holdings Co., Ltd., Baidu Online Network Technology (North
Beijing) Co., Ltd., Chengdu Weishitong Information Industry Co., Ltd.
The main drafters of this standard. Mu Changchun, Li Wei, Di Gang, Yao Qian, Yang Fuyu, Li Xingfeng, Qu Weimin, Zhao Xinyu, Qian Youcai, Zhang
Hongbo, Shi Zhan, Zhang Honghui, Cui Peidong, Wang Yanbo, Lin Hua, Chen Zhong, Zhang Dawei, Zhou Ziheng, Su Heng, Wang Peng, Xiao Yao, Wang Weiqiang,
Fan Yuanyuan, Wu Weisi, Zhang Yuming, Li Bin, Zuo Min, Yu Xiao, Lu Haining, Zhong Sheng, Cai Liang, Lian Na, Wei Kai, Wen Yuhui, Chen Cong, Cao
Peng, Xiao Wei, Wu Bo.
Introduction
Distributed ledger technology is a high integration of multiple core technology systems such as cryptographic algorithms, consensus mechanisms, peer-to-peer communication protocols, and distributed storage.
A distributed infrastructure and computing paradigm formed by the combination. At the stage when the form of distributed ledger technology is still plastic, it is necessary to formulate key
Technical safety regulations, so that financial institutions can deploy and maintain systems in accordance with appropriate safety requirements, avoid security shortcomings, and provide
The large-scale application of the ledger technology provides business assurance capabilities and information security risk restraint capabilities, and has a positive effect on industrial applications.
To implement the "Thirteenth Five-Year Development Plan for Information Technology in China’s Financial Industry" (Yinfa [2017] No. 140) and "Financial Technology
(FinTech) Development Plan (2019-2021)” (Yinfa [2019] No. 209 issued), standardize the distributed ledger technology in
The application of the financial field to improve the information security guarantee capability of distributed ledger technology, this standard is specially formulated.
Financial Distributed Ledger Technology Security Specification
1 Scope
This standard specifies the security system of financial distributed ledger technology, including basic hardware, basic software, cryptographic algorithms, node communication,
Ledger data, consensus agreements, smart contracts, identity management, privacy protection, regulatory support, operation and maintenance requirements, and governance mechanisms.
This standard applies to institutions engaged in the construction of distributed ledger systems or service operations in the financial sector.
2 Normative references
The following documents are indispensable for the application of this document. For dated reference documents, only the dated version applies to this document.
For undated references, the latest version (including all amendments) applies to this document.
GB/T 22239-2019 Information Security Technology Network Security Level Protection Basic Requirements
GB/T 32905-2016 Information security technology SM3 cryptographic hash algorithm
GB/T 32907-2016 Information Security Technology SM4 Block Cipher Algorithm
GB/T 32918-2016 (all parts) Information Security Technology SM2 Elliptic Curve Public Key Cryptography Algorithm
GB/T 35273-2017 Information Security Technology Personal Information Security Specification
GB/T 37092-2018 Information Security Technology Cryptographic Module Security Requirements
GM/T 0006-2012 Code Application Identification Specification
GM/T 0009-2012 SM2 cryptographic algorithm usage specification
GM/T 0010-2012 SM2 cryptographic algorithm encryption signature message syntax specification
GM/T 0015-2012 Digital certificate format specification based on SM2 cryptographic algorithm
GM/T 0028-2014 Security technical requirements for cryptographic modules
GM/T 0039-2015 Password module security testing requirements
GM/T 0044-2016 (all parts) SM9 identification password algorithm
GM/T 0045-2016 Financial Data Cryptographic Machine Technical Specification
GM/T 0054-2018 Information system password application basic requirements
3 Terms and definitions
The following terms and definitions apply to this document.
3.1
Digital signature
The data attached to the data unit, or the cryptographic transformation of the data unit, which allows the reception of the data unit
It is used to confirm the source and integrity of the data unit, and to protect the data from being forged or denied by others (such as the recipient).
[GB/T 25069-2010, definition 2.2.2.176]
3.2
Hash function
A function that maps a bit string to a fixed-length bit string. The function satisfies the following two characteristics.
--For a given output, it is computationally infeasible to find the input mapped to the output;
--For a given input, finding the second input that maps to the same output is computationally infeasible.
Note. The computational feasibility depends on the specific safety requirements and environment.
[GB/T 25069-2010, definition 2.2.2.166]
3.3
Symmetric cipher
A cryptographic technique that uses the same secret key in both encryption and decryption algorithms.
[GB/T 25069-2010, definition 2.2.2.26]
3.4
Asymmetric cipher
Based on the system of asymmetric cryptography, public transformation is used for encryption and private transformation is used for decryption. vice versa.
[GB/T 25069-2010, definition 2.2.2.30]
3.5
Random number
A time-varying parameter whose value is unpredictable.
[GB/T 25069-2010, definition 2.2.2.182]
3.6
Certificate
A type of data about an entity that is signed by the private key or secret key of the certification authority and cannot be forged.
[GB/T 25069-2010, definition 2.2.2.218]
3.7
CA certificate CA-certificate
A certificate issued by one CA to another CA.
[GB/T 25069-2010, definition 2.2.2.219]
3.8
Access control
A means to ensure that the resources of the data processing system can only be accessed by authorized subjects in an authorized manner.
[GB/T 25069-2010, definition 2.2.1.42]
3.9
Zero-knowledge proof
A method used to verify that a certain witness knows a certain secret without revealing the secret and related information.
3.10
Group signature
Any member of a group can sign a message on behalf of the entire group anonymously.
3.11
Ring signature
The signer specifies a set (or ring) of possible signers and signs a message. The verifier can be sure that the signature
A member of is generated, but the real signer cannot be pointed out.
3.12
Privacy protection
Measures taken to protect privacy. For example. restrictions on the collection, processing and use of personal data.
[GB/T 25069-2010, definition 2.2.1.122]
3.13
Identity-based cryptographic algorithm
The user’s public and private key pair is generated through the user’s identity, which is mainly used for digital signature, data encryption, key exchange and personal identification.
Certification, etc.
3.14
Homomorphic encryption
A form of encryption that uses specific algebraic operations to process encrypted data to obtain an output, which is decrypted, and the result is
The result is consistent with the output result obtained by processing unencrypted data in the same way.
3.15
Secret sharing
A cryptographic technique that divides and stores a secret (key), which can be pieced together by combining the divided parts.
3.16
Peer-to-peer network
A computer network that contains only nodes equivalent to control and operation capabilities.
3.17
Consensus protocol
The calculation method used to reach agreement among nodes in the distributed ledger system.
3.18
Distributed ledger
A database that can be jointly managed and shared in a network composed of multiple sites, different geographic locations, or multiple institutions.
3.19
Distributed ledger technology
A collection of technologies that implement distributed ledgers, which are the cores of cryptographic algorithms, consensus mechanisms, point-to-point communication protocols, distributed storage, etc.
A distributed infrastructure and computing paradigm formed by the highly integrated technology system.
3.20
Smart contract
A computer protocol designed to spread, verify, or execute contracts in an information-based way, which is embodied in a distributed ledger that can be automatically executed
Computer program.
3.21
Denial of service
An attack that makes the system unavailable.
[GB/T 25069-2010, definition 2.2.1.75]
3.22
Node
An entity that provides all or part of the functions of a distributed ledger.
3.23
Transaction validation node
The node responsible for verifying the submitted transaction data.
3.24
Consensus node
The node responsible for the consistency of the ledger data.
3.25
Accounting node
The node responsible for the integrity of the ledger data.
3.26
Authentication code
The bit string output by the message authentication code algorithm.
Note. The message authentication code is sometimes called the password check value.
[GB/T 25069-2010, definition 2.2.2.65]
3.27
Data integrity
The data has not been altered or destroyed in an unauthorized manner.
[GB/T 25069-2010, definition 2.1.36]
3.28
Confidentiality
The feature that prevents information from being disclosed to unauthorized individuals, entities, processes, or being used by them.
[GB/T 25069-2010, definition 2.1.1]
3.29
Unlinkability
The anonymous identity shown by the same user during multiple transactions cannot be restored to the same user.
3.30
Consistency
In a certain system or component, the degree of uniformity, standardization and non-contradiction between documents or parts.
[GB/T 25069-2010, definition 2.1.62]
3.31
Finality
Once the transaction is confirmed, it will not be rolled back or cancelled.
3.32
Incentive compatibility
A kind of institutional arrangement that makes the behavior of the actor to pursue individual interests coincides with the goal of maximizing value as a whole.
3.33
Local broadcast
It avoids the spread of information on the entire distributed ledger by only sending information to authorized related party nodes.
3.34
Mixing
By severing the relationship between the parties to the transaction, the transaction flow is difficult to be analyzed and tracked to protect the details of the transaction.
3.35
Local clustering coefficient
A coefficient indicating the degree of aggregation of individual nodes in a graph.
3.36
Atomicity
If an error occurs during the execution of the smart contract, it will be rolled back to the state before the start of the smart contract.
3.37
Turing complete
In the theory of computability, a series of rules for manipulating data (such as instruction sets, programming languages, cellular automata) can be used to simulate single
With Turing machine.
3.38
Non-repudiation
Also called non-repudiation, it proves the undeniable nature of an operation that has occurred.
[GM/Z 0001-2013, definition 2.46]
3.39
Identity information
Information that can be used alone or in combination with other information to identify and track the identity of a specific natural person or reflect the activities of a specific natural person.
3.40
Privacy
It has nothing to do with the public interest, except that it can only be used publicly for the party who has the obligation to keep confidential, the personal information that the party does not want a third party to know and
The personal domain that the party does not want a third party to invade.
Note. The three elements of privacy protection.
--The subject of privacy is a natural person;
--The object of privacy is the personal information and personal fields of natural persons;
--Privacy content refers to facts or behaviors that specific individuals do not disclose their information or domains, and do not want others to detect or interfere.
3.41
Private information
The identification information of a specific natural person and its activity information in a specific system.
3.42
Personal information
Recorded electronically or in other ways that can identify a specific natural person alone or in combination with other information or reflect a specific nature
Various information about people’s activities.
Note. Personal information includes name, date of birth, ID number, personal biometric information, address, communication contact information, communication records and content,
Account password, property information, credit information, whereabouts, accommodation information, health and physiological information, transaction information, etc.
[GB/T 35273-2017, definition 3.1]
3.43
Controller
A natural person, legal person or other organization that determines the purpose and method of processing personal information alone or jointly with others.
3.44
Intervention mechanism
Prohibiting or restricting specific behaviors of specific roles participating in the financial distributed ledger system is an emergency braking measure provided for abnormal situations.
3.45
Block cipher
The cryptographic algorithm used performs operations on the plaintext block (that is, a bit string with a defined length) to generate a symmetric cryptogram of the ciphertext block.
[GB/T 25069-2010, definition 2.2.2.82]
3.46
Stream cipher
A symmetric cryptosystem with the following properties. its encryption algorithm uses a certain reversible function to combine the sequence of plaintext symbols with the sequence of key stream symbols.
Combine them one symbol at a time for transformation. It can be divided into two types. synchronous stream/serial cipher and self-synchronous stream/serial cipher.
[GB/T 25069-2010, definition 2.2.2.85]
3.47
Key exchange
Securely establish a shared key negotiation process between communicating entities.
[GB/T 25069-2010, definition 2.2.2.119]
4 Abbreviations
The following abbreviations apply to this document.
5 Security System Framework
The security system of financial distributed ledger technology includes basic hardware, basic software, cryptographic algorithms, node communication, ledger data, and consensus protocols.
Discussion, smart contracts, identity management, privacy protection, regulatory support, operation and maintenance requirements, and governance mechanisms. Financial distributed ledger technology security
The whole system framework is shown in Figure 1.
6 Basic hardware
6.1 Basic requirements
The basic hardware environment should follow the physical and network-related requirements of Level 3 and above in GB/T 22239-2019.
6.2 Physical security
6.2.1 Site safety
The deployed physical data center and ancillary facilities meet the following requirements.
--For the cloud deployment model, ensure that the operating environment of the data center used in the financial industry is located in a high-security area;
--For system nodes that undertake the functions of consensus nodes or bookkeeping nodes, it is advisable to ensure the business operation and data of financial distributed ledger users
The physical equipment for storage and processing is located in China.
6.2.2 Hardware equipment
It should monitor the operating status of equipment and resource usage, and be able to issue alarms when abnormal conditions occur.
It shall be ensured that the data carried by the equipment and storage media can be cleared and cannot be restored when they are reused, scrapped or replaced.
It should be ensured that the hardware devices used by different nodes have a certain degree of heterogeneity.
For the cloud deployment model, with the cooperation of the cloud environment service provider, the cloud environment should be guaranteed to have a certain degree of heterogeneity.
6.2.3 Node deployment security
Redundant deployment of key nodes should be guaranteed to ensure system availability.
It should be avoided to deploy all nodes undertaking consensus or accounting in the same computer room, and it should be able to ensure the integrity of the system when a single computer room node is unavailable.
Physical availability.
It should be ensured that distributed ledger nodes with unsuitable data are placed inside the organization or in a protected area.
It should be ensured that the storage capacity of the hardware equipment of the deployed node can be expanded to avoid the inability to synchronize the ledger because the data capacity reaches the upper limit.
6.2.4 Hardware encryption device security
For a distributed ledger system that uses hardware encryption equipment to complete cryptographic operations and key storage, the hardware encryption equipment used should meet the following requirements
Claim.
--The encryption machine equipment used should meet the requirements of GM/T 0045-2016 promulgated by the national password management department;
--The personal password equipment used (such as UKey, encryption card, mobile terminal with SE or TEE, etc.) should comply with the industry authorities and
The requirements of the national password management department.
6.3 Cybersecurity
6.3.1 Network architecture security
It should be ensured that there can be direct network communication or indirect message transmission between consensus nodes or accounting nodes.
In the network topology, a single node failure should be prevented to form network isolation.
It should be ensured that each important node has a large local clustering coefficient.
6.3.2 Communication transmission security
A secure transmission channel should be established between the nodes participating in the distributed ledger to ensure the integrity and non-tampering of data transmission.
Corresponding protective measures should be taken for data and information to ensure that it can resist active or passive attacks such as tampering and replay.
Cryptographic technology should be used to ensure the confidentiality of sensitive information fields or the entire message in the communication process between nodes, and to ensure that information is stored and transmitted.
It will not be read or tampered by unauthorized users during the input process.
Authorized network access control can be used to construct a virtual private network (VPN) between participating distributed ledger nodes to reduce network
The harm caused by the attack.
7 Basic software
7.1 Basic requirements
The basic software environment should comply with the host security, application security, data security and backup and recovery phases of GB/T 22239-2019 and above.
Related requirements, it should also include ledger structure, consensus module, distributed networking, data storage, smart contracts, interface design, data transmission, time
Synchronization and operating system requirements.
7.2 Ledger structure
The ledger structure should be tamper-proof. The ledger structure should use a block chain or a similar block chain storage structure, and the hash nesting guarantee should be used
The data is difficult to tamper with.
The ledger should have a data verification function. After any record is illegally tampered with, it can be traced back through historical ledger data for quick verification.
7.3 Consensus module
The consensus module should be able to coordinate all system participants to participate in the data packaging and consensus process in an orderly manner, and ensure the data consistency of each participant.
When the system has no faulty nodes or fraudulent nodes, it should be able to reach an unanimous and correct consensus within the specified time and output correct results.
In the case that the total number of failed nodes and fraudulent nodes does not exceed the theoretical value, the system should work normally.
7.4 Distributed networking
The system participant nodes should be separated in physical deployment, and each node communicates and exchanges data based on network communication protocols and peer-to-peer networks.
change.
Each node should independently store consistent ledger data, and ensure that any single node failure does not affect the normal work of the entire system.
Made.
The system is interconnected by nodes distributed in different locations, and there is no central node in the network. The communication control function should be distributed on each node,
And any node establishes a communication connection with at least two other nodes.
7.5 Data storage
Ledger data should be stored independently according to the type of d...
Tips & Frequently Asked Questions:Question 1: How long will the true-PDF of JR/T 0184-2020_English be delivered?Answer: Upon your order, we will start to translate JR/T 0184-2020_English as soon as possible, and keep you informed of the progress. The lead time is typically 4 ~ 6 working days. The lengthier the document the longer the lead time. Question 2: Can I share the purchased PDF of JR/T 0184-2020_English with my colleagues?Answer: Yes. The purchased PDF of JR/T 0184-2020_English will be deemed to be sold to your employer/organization who actually pays for it, including your colleagues and your employer's intranet. Question 3: Does the price include tax/VAT?Answer: Yes. Our tax invoice, downloaded/delivered in 9 seconds, includes all tax/VAT and complies with 100+ countries' tax regulations (tax exempted in 100+ countries) -- See Avoidance of Double Taxation Agreements (DTAs): List of DTAs signed between Singapore and 100+ countriesQuestion 4: Do you accept my currency other than USD?Answer: Yes. If you need your currency to be printed on the invoice, please write an email to [email protected]. In 2 working-hours, we will create a special link for you to pay in any currencies. Otherwise, follow the normal steps: Add to Cart -- Checkout -- Select your currency to pay.
|