General Information English - usechain/doc GitHub Wiki

（Translation not finish yet ）

Overview

Since the identity in reality have multiple dimensions and complexity, Identity Authentication needs to be flexibly designed，to meet the various needs. For convenience, we designed the special Usechain Hierarchical Identity System. This system supports centralized PKI (Public Key Infrastructure) mechanism and distributed authentication by group intelligence. That means the system can protects privacy very well, but also has a good ability to be a regulatory system. We abstracted a credit rating and credit scores for user credit's viewing. This design is compatible with most of financial and business scenario.

Identity Level：

word construction

Entity/User： Includes physical and virtual entities.Such as natural person, organizations (enterprises, units, groups, institutions, etc.), hardware (cars, mobile phones, refrigerators, sensors, etc.), virtual entities.

Identity Number：The entity‘s identity which mapped on the chain, called it UseID in Usechain system. And each user will have a independent logo indicating the identity already be authenticated

Standards of Star：Credit rating standard on the Usechain. User's credit can be divided into 4 categories: trading score, certification score, evaluation score and rewards and punishments.

The trade score is depend on transaction history.

The certification score is the credit score based on various certifications.

The evaluation score is the evaluation given by each counterparty in trading history.

Architecture

Law Committee: Decision maker, handle the identity management, selected by election. And to be a law committeer, the Identity Level should reached level 3, and lock a certain number of USE in the Committee Smart Contract.

Executive Committee: Mainly responsible for Usechain system administration, marketing and daily operations.

Technical Committee: Responsible for the direction of technology development.

CA(Certification Authority): Socially recognized certification institution with great authority, and qualification must be confirmed by the committee in advance.

Law Committee

At the beginning, the law committee have 5 members. With the improvement of the governance, will be expanded to 9 or 11 as needed. In the first five years, the Usechain Foundation retained three permanent members which doesn't selected by election for security consideration. After that, every member should be selected by vote election.

rights and interests

Decision Maker of Usechain, but all the decision should obtain 2/3 members' agreement.

Interests

The committee's interest could divided into three part.

  1. Steady income
  2. Work income
  3. Motivate

Steady income

Committee member will get certain number of USE every year.

Work income

Based the identity verfication work and dispute trial.

Motivate

Not designed in detail yet.

Committee Election

The chain code limits the committee's term of office to one years.

And every entity passed the identity authentication， will got the voting rights

Miner

Responsible for block packing and chain running

Only passed Identity Authentication Level 3, can get the right to a miner。

Mined 1 block, will get 15 USE

Credited User

  • Should passed basic identity authentity, such as Nation ID Verification or Passport Verification.
  • Credit Score reached level 3.

Anonymous User

  • Haven't do any identity authentication
  • May have trading amount and frequency limits

Identity Info Storage

The certification and basic personal info will be stored on the chain after been encrypted，such as DID, CN and SerialNumber.

Usechain will not keep other personal info for security consideration and chain performance, just record the data hash on the Identity Smart Contract.

Identity Format

follow the w3c DID standard，use the JSON-LD data format。

Every nature person get only one UseId, like UUID.

Every UseId can have kinds of feature. Each feature can be authenticated in independent

Identity Info standard

Separate the identity info and issuer info for the reason that user's info can be authenticated by not only one issuer

Example

{
    "@context": "https://usechain.net/useid/v1",
    "useid": "[abc123]",
    "address":"[]",
    "pubkey": "[公钥1pem]",
    "claim": {
        "identity": {
            "[idhash]": {
                "data": "[djajslaldkdk(用户公钥加密身份)]",
                "nation":"cn",
                "entity":[0/1/2/3], 
                "fpr":"[fpr123]",
                "alg": "RSA",
                "certype": "[1身份证]",
                "ver": 1,
                "cdate": "2018-11-01T17:00:00Z"
            },
            "[idhasha]": {
                "data": "[加密数据]",
                "fpr":"[fpr123]",
                "alg": "RSA",
                "certype": "[2护照]",
                "ver": 1,
                "cdate": "2018-11-01T17:00:00Z"
            },
            "[idhashx]": {
                "data": {
                    "id": "[12345678]",
                    "certype": "[100营业执照]",
                    "name": "区块之星",
                    "nation": "cn",
                    "addr": "beijing...",
                    "bdate": "2018-11-01",
                    "edate": "2028-11-01",
                    "[经营范围]": "[xxxxx]"
                },
                "fpr":"[fpr123]",
                "alg": "PLAIN",
                "certype": "[100企业执照]",
                "ver": 1,
                "cdate": "2018-11-01T17:00:00Z"
            }
        },
        "edu": {
            "[hashedu]": {
                "data": "[djdjaj]",
                "fpr":"[fpr123]",
                "alg": "ECC",
                "certype": "[4学习证明]",
                "ver": 1,
                "cdate": "2018-11-1T17:00:00Z"
            }
        },
        "assets": {
            "[hash122]":{
                "data":"[djdjdj]",
                "fpr":"[fpr123]",
                "alg": "ECIES",
                "certype": "[20不动产证明]",
                "ver": 1,
                "cdate": "2018-11-1T17:00:00Z"
            }
        },
        "career": {
            "[careerhash1]": {
                "data": "[djdjhhaj(pubkey加密后数据)]",
                "fpr":"[fpr123]"
                "alg": "ECC",
                "certype": "[5工作证明]"
                "ver": 1,
                "cdate": "2018-11-1T17:00:00Z"
            }
        },
        "other": {}


    },


    "issuer": {
        "[hashedu]": {
            "[useid of ustcca]": {
                "sign":"[sign...]",
                "cdate":"20181028",
                "edate":"[20281028本字段可选]"
            }
            "[useid of 学信网ca]": {
                "sign":"[sign...]",
                "cdate":"20181028",
                "edate":"[20281028可选]"
            }
            
        },
        "[idhash]": {
            "[useid of 身份证认证中心ca]":{         "sign":"[...]",
                "cdate":"20181028",
                "edate":"[20281028可选]"
            }
        },
        "[birthdayhash]": {
            "[useid of hospital_certid]":{ "sign":"[hospital birth cert]",
            "cdate":"20181028",
            "edate":"[20281028可选]"
            }
        },
        "[careerhash1]": {
            "[useidxxx]": {
                "sign": "[sign for careerhash1]",
                "pubkey": "[useidxxx pubkey]",
                "cdate":"20181028",
            "edate":"[20281028可选]"

            },
            "[useidyyy]": {
                "sign": "[sign for careerhash1]",
                "pubkey": "[useidyyy pubkey]",
                "cdate":"20181028",
            "edate":"[20281028可选]"

            }
        }
    }
}

Context Example

"@context":{
    "useid":"address:40",
    "address":"string:256",
    "name":"string:256"
}

Identity Example：

{
	"info": {
		"identity": {
			"hash256(certtype-id)": {
				"id": "123456(身份证号码)",
				"certype": "1(身份证)",
				"name": "张三",
				"sex":"1",
				"ename":"zhang san(opt)",
				"nation": "中国",
				"addr": "beijing...",
				"birthday": "2008-11-01"
			}
		},
		"edu": {
			"hash256": {
			    "id":"123456",
			    "certype":"4学位证",
				"school": "ustc",
				"degree": "be",
				"depart": "computer",
				"bdate": "1995-09-01",
				"edate": "2000-07-01"
			}
		},
		"assets": {
		    "hash128122":{
		        "id":"daa323",
		    	"addr":"ssdfddd"
				"owner":"asdf",
				"ownerid":"234234",
		        "certype": "20不动产证明",
		    	"nation": "cn",
		    	"share":"1.0"
		    	"area":"100m2"
				"cdate": "2018-11-1T17:00:00Z"
		    },
		    "hash256":{
		        "id":"djaja",
		        "owner":"djdjdj",
		        "ownerid":"dasdf",
		        "brand":"bmw",
		        "model":"2016",
		        "certype":"21汽车行驶证",
		        "nation": "cn",
		        "cdate": "2018-11-1T17:00:00Z"
		    }
		    
		},
		"career": {
			"careerhash1281": {
				"org": "acompony",
				"base": "beijing",
				"depart": "ai",
				"bdate": "1995-09-01",
				"edate": "2000-07-01"
			}
		},
		"other": {}
	}
}

其中，数据的chash是keccak 256摘要算法对值的摘要。 如下面的工作经历数据：

{
    "org":"acompony",
    "base":"beijing",
    "depart":"ai",
    "bdate":"1995-09-01",
    "edate":"2000-07-01"
}

将其去除空格，tab和换行，成为

{"org":"acompony","base":"beijing","depart":"ai","bdate":"1995-09-01","edate":"2000-07-01"}

再进行hash256计算，最后得到的hash值是用于上链中一个元数据fpr。

索引hash是证件certype+id的hash256计算结果。 如果没有证件号，则采用fpr做索引。

如对身份证，数据如下：

{
    "id": "123456(身份证号码)",
	"certype": "01身份证",
	"name": "张三",
	"sex":"1",
	"nation": "cn",
	"addr": "beijing...",
	"birthday": "2008-11-01"
}

用certype和id拼接再hash。certype由规范规定，见后。

hashid=hash(certype-id)

如员工的工作经历，没有证件号，可以将fpr数据做索引.

则写到“claim/career”里面的一项即为

"careerhash256":{
    "org":"acompony",
    "base":"beijing",
    "depart":"ai",
    "bdate":"1995-09-01",
    "edate":"2000-07-01"
}

如果采用数据fpr做索引，修改了其中任何一项，则会导致hash的改变。

生成data过程

索引为certype+id对应的hash：“idhash256”。 值为

{
    "id":"123456",
    "certype":"身份证",
    "name":"张三",
    "nation":"cn",
    "addr":"beijing...",
    "birthday":"2008-11-01"
}

计算finger print： 将值里面的数据去空格、制表和换行等无效信息。即为：

{"id":"123456","certtype":"身份证","name":"张三","nation":"cn","addr":"beijing...","birthday":"2008-11-01"}

再用用户公钥pubkey进行加密。加密算法可以为RSA或者ECC。 最终生成：

"hash256":{
        
    "data":"djajslaldkdk(用户公钥加密身份)",
    "alg":"ECIES",
    "pubkey":"pubkeydjjd",//加密data用的公钥
    "fpr":"djjajakak",
    "certype":"01",
    "cdate":"2018-11-1"

}

如果不加密，则为

hash256":{
        
    "data":"{
    
    "id":"123456",
    "certype":"身份证",
    "name":"张三",
    "nation":"cn",
    "addr":"beijing...",
    "birthday":"2008-11-01"

}",
    "alg":"PLAIN",
    "certype":"1(opt)",
    "cdate":"2018-11-1"

}

放到"info/identity"下面的位置。 经过认证后，在auth节添加相应的签名或证书。

公钥生成：

设用户主账号的公私钥为(U,u)。 用户先生成一个普通的公钥A和对应的私钥a。再生成一个随机的公钥R和私钥r。委员会的公钥为C，私钥为c。

U= Hash(aC) G + R
u= Hash(aC) + r

用公钥U对示例1的具体数据进行加密，得到data。

Info Update

Only the committee & user self can update the identity info logged on the chain

Authentication Process

  1. CA发身份认证信息。其中证书请求的name填hash(certype+id).
  2. CA服务器返回一个查询id。
  3. 向CA支付一定费用。
  4. 向CA查询证书。
  5. CA服务器验证通过后，用户可以获取证书。
  6. 用户将身份信息用委员会公钥加密，以及用自己公钥加密，携带证书和认证费用，发到委员会认证智能合约。
  7. 委员会从智能合约获取验证数据。某个委员看到指定由自己验证，则进行数据合法性和证书合法性验证。
  8. 验证通过，收取费用，验证上链。

从细节上，用户主账号公私钥为(m，M)。随机匿名账号公私钥为(r,R)。委员会公钥为C，委员会某个成员的公钥为C1.

用户向委员会认证合约发起注册请求，至少包含下列必要信息：

hash:{
    data:xxx
    fpr:xkxk
    alg
    cdate
    edate
}
data1
C1
cert or sign
  • hash：为keccak256(certype+id)
  • fpr: 位keccak256(claim)，claim为用户身份信息
  • alg：加密算法，如ECC
  • cdate:开始日期
  • edate：结束日期

其中，data和data1算法：

data = encrypt_M(claim)

data1 = encrypt_{C1}(claim)

CA认证

基于中心化PKI体系进行认证。CA中心可以是政府单位，具有公信力的组织及其派出和代理执行机构。

如在中国，身份证，驾驶证，护照，户籍，学籍，社保，房产证等均可以作为CA证书认证来源。

认证会花费一定手续费。
CA机构会颁发相应的证书。
CA机构由社会上本来具有公信力的机构颁发证书或Usechain委员会认定合作单位颁发证书。

互相认证

证明者对身份进行认证。 由身份1级以上用户，可以对其他用户进行认证。 认证后，被认证用户获得相应认证分数。同一用户对同一事项反复认证只记一次，也不会有额外的积分。 认证分数：

认证分数=证明者级数*1000

(不设首次和其余不同是为了简化规则，提高效率)

身份链上注册

将委员会认可的CA认证机构或链上具有1级以上个人认证信息发送到链上合约注册，成功后添加相应UseId的等级分。

隐身交易

用户可以签名子账号，使子账号具有签名账号的信用等级，和目标用户交易。账号之间的关联只有目标用户和委员会知道。普通成员无法发现子账号和签名账号之间的关系。

假设交易账号A，私钥a由Alice拥有，不想泄露该账号的交易。可以生成隐身交易的子账号，公钥为X，私钥为x。生成时会利用一个随机的公钥R和私钥r。接受方Bob的公钥为B,私钥b. 委员会Committee的公钥为C，私钥为c。

从DID1中获取一个pubkey A对应的私钥 a,

x生成：

X= Hash(aC)G + R
x= Hash(aC) + r

并将{X，r}注册到Usechain委员会。获得相应Useid，委员会将A的等级赋给X。

即X子账号诞生时具有与主账号A相同的信用等级，但诞生后不再和A共享信用等级，互相独立。如果主账号和子账号作恶，则会互相牵连。

用a对X签名，再用S加密，得到signa。交易时携带该signa，让S验证。

接受用户得到signa后，先用s解密，再验证a的签名。 如果a的签名正确，则接收方可以认为X共享A信用和相关证书。

身份信息交换

用户的身份，采用用户公钥加密保存在链上，并附加各认证者的签名。 Alice，密钥为A,a,现在需要和Bob,密钥为B，b进行身份验证，即Alice要发送身份给Bob验证。 假设Alice身份信息如DID1，想交换身份证"info/identity/idhash128". 其明文如下：

"hash256":{
    "id":"123456",//身份证号码
    "certype":"身份证",
    "name":"张三",
    "sex":1,
    "country":"中国",
    "address":"beijing..."
    "birthdate":"2008-11-01"
}

其保存在链中的信息如下：

"hash256":{
    "data":"djajslaldkdk(用户公钥加密身份)",
    "alg":"RSA",
    "pubkey":"pubkeydjjd",//加密data用的公钥
    "certype":"01",
    "fpr":"sdjdjaj",
    "cdate":"2018-11-1"

}

Alice根据自己Useid，取出链中的"info/identity/idhash128/data",用私钥a和算法RSA解密，得到明文。 Alice将明文用Bob的公钥B加密，发送一个交易给Bob。 Bob收到后，发现是一个身份验证的交易。于是用自己私钥b解密，得到明文。对明文进行hash，得到idhash128_1,再读出Alice的Useid中的"info/identity/idhash128/data,pubkey,alg"等信息，比较hash和chash值是否一致。用明文采用RSA和pubkeydjjd公钥加密，得到data_1，比较data和data_1是否一致。如果hash，chash和data都一致，则验证无误。

身份类型

1：身份证
2：护照
3：驾驶证
4：社保证

10：教育证

20：不动产证明
21：存款证明
22：汽车
23：股票

30：工作证明

40：其他

50：企业执照