签名介绍

Posted 2023-05-09 Pam

群签名、环签名、盲签名、门限签名、代理签名和双重签名等

介绍

传统签名

• RSA签名：基于大整数难分解问题
• ElGamal签名：基于离散对数问题
• Schnorr签名：基于有限域上的离散对数问题
• DSA：基于离散对数问题
• ECDSA签名：基于椭圆曲线上的离散对数问题

特殊签名的大致理解：

• 群签名：有一个类似管理员的角色，给所有人签名（是有中心的）
• 环签名：不是所有人都签名，只有部分人签名，但具体不知道是谁，具有匿名性【是去中心化的】
• 盲签名：签名者不知道签名内容
• 门限签名：需要多个人的子密钥一起完成签名
• 代理签名：将密钥授权给第三方，由第三方完成签名
• 双重签名：在签名者和验证者之间有一个中间人，进行验证授权

群签名

介绍

1991 年，Chaum 和 Heyst 给出了群签名的概念，基本思想是一群人中的任意一个人可生成一群签名，外界可验证其合法性，即此签名的确为群中的某人生成，但不能确定到底是谁签的【隐私保护】，当在发生争议时，可由具有特权的群管理员“打开”争议的签名，找出真正的签名者【可追踪】。

由于群签名具有隐私保护和可追踪的特性，可广泛应用电子商务、电子货币、可信计算、网络取证、电子选举等领域。

群签名方案构建分为ROM模型和标准模型。

• ROM模型：将hash函数看作是一个理想化的随机Oracl（现实中不存在）构造签名，安全性不充分；
• 标准模型：是相对比于ROM模型，不将hash函数看作是一个理想化的随机Oracl，更加接近现实，因此构建出的安全方案具有更高的安全性；

群签名应具有以下性质：

• 正确性：合法签名者生成的签名可以被验证通过；
• 不可伪造性：只有群成员才能进行签名；
• 匿名性：给定一个合法群签名，只有管理员才能识别出真正的签名者；
• 不可链接性：判断两个群签名是否由一个成员签发的，在计算上是不可行的；
• 防陷害性：管理员或任意成员都不代表该成员生成签名；
• 可追踪性：管理员总能够打开一个合法的群签名，并找出真正的签名者
• 抵抗合谋攻击：任意一些群成员合谋（包括管理员）也不能生成一个合法的群签名，使得管理员可以打开，但其他群成员打不开的情况

方案

群签名方案的成员主要包括群管理员和若干群成员，一个完备的群签名方案由以下算法组成：

• 系统建立：
  • 输入安全参数，群管理员生成一个群公钥GPK（用于群签名验证）、一群私钥GSK（用于生成成员证书和打开签名）；
• 成员加入：
  • 对于动态的群签名，新用户与管理员之间交互，完成后新用户加入群并获得成员证书和一个私钥（用于群签名的生成），管理员获得相关的追踪信息，用于打开签名，从而完成追踪；
  • 对于静态的群签名：管理员直接生成成员证书，并秘密传送给新用户，过程没有交互，缺点是管理员可能会冒充成员进行签名；
• 签名：群中任意成员利用自己的成员证书和私钥生成消息的群签名；
• 验证：任何人获得GPK和一个（消息，签名）对，可验证此签名是否合法，且对于合法的签名，不知道具体的签名者是谁；
• 打开：对于合法的群签名，管理员能打开并找出实际的签名者，管理员会给出证据，说明该签名的确是某成员签的，同时不会破坏此成员未来的签名能力；
• 撤销【部分支持】：管理员可以撤销某成员的签名权利，之后此用户就不能生成合法的群签名了；

原理

待补充

环签名

最初由Rivest和Tauman提出，根据群签名而提出，与群签名的区别是：环签名方案允许签名者在一组成员中保持匿名、环签名中不需要群管理员，没有群成员预设机制，没有更改和删除群机制。签名者直接指定任意环，然后在不经过其他成员许可或协助的情况下进行签名，如果要生成有效的环签名，签名者需要知道其私钥和其他成员的公钥。

盲签名

1982年Chaum首次提出了盲签名的概念，在盲签名中，用户可以获得签名者的签名，而签名人却不知道所签消息的内容。保证了签名方案的匿名性和不可追踪性，当（消息，签名）被公开后，签名者也无法获知消息和签名过程间的关系。1992年，Okamoyo提出了一种基于大数分解和离散对数的盲签名方案，基于Schnorr和Guillon的协议，Pintcheval和Stern提出了一种可证明安全的盲签名方案，2009年，Overbeck提出了首个基于编码的盲签名方案。

盲签名可广泛应用于各种匿名性场合，比如电子支付、电子投票等。

电子投票应用

下面介绍一个基于RSA盲签名的电子选举系统

• 电子选举

选举委员会发布选举人名单，投票人在选票上标记自己的意向候选人；为使得选票有效，该选票需要经过选举委员会的签名确认，既要得到选举委员会对选票的签名，又不能泄漏选票内容，此时使用盲签名可以完成该功能。

• 密钥生成：\\(N=pq\\)，\\(PK=(e,N),SK=(d)\\)

• 投票人盲化数据

部分盲签名

在盲签名中签名人完全不知道最终签名的任何消息，将在电子现金系统中造成数据库无限增长的问题，为了解决该问题，1996年，Abe等提出了部分盲签名的概念。

部分盲签名允许签名人在签名中嵌入与用户事先协商好的公共信息，且这些公共信息不能被移除或非法修改。在电子现金系统中，银行可将有效期、面值等信息嵌到其发行的电子钱币中，这样银行就能避免维持开销无限增长的数据库的困境。如果将公共信息设为同样值，则部分盲签名就可以转换为完全盲签名，因此部分盲签名可以看作是盲签名的一种形式。

方案

• 建立

选择阶为\\(q\\)的循环群\\(G_1\\)和\\(G_2\\)，定义双线性对\\(e:G_1 * G_1\\to G_2\\)；任意选择群\\(G_1\\)的生成元\\(P\\)；定义两个哈希函数\\(H_1:\\left \\0,1 \\right\\^*\\to G_1\\)，\\(H_2:\\left \\0,1 \\right\\\\to Z_q\\)，系统参数为\\(params=(G_1,G_2,e,q,P,H_1,H_2)\\)。

• 密钥生成

签名人任意选择\\(x\\in Z_q\\)，计算\\(P_pub=xP\\)，其中签名人的公钥为\\(P_pub\\)，私钥为\\(x\\)。

• 签名发布

假设\\(c\\)为实现协商好的公共信息，\\(m\\)是要签名的消息，则签名者和用户的交互如下：

1. 盲化：用户随机选择\\(r\\in Z_q\\)，计算\\(U=rH_1(m,c)\\)，并将\\(U\\)发送给签名人；
2. 签名：签名人计算\\(V=(H_2(c)+x)^-1U\\)，并将\\(V\\)发送给用户；
3. 解盲：用户计算\\(S=r^-1V\\)，并输出部分盲签名\\((S,m,c)\\)；

• 验签

检查等式\\(e(H_2(c)P+P_\\operatornamepub,S)=e(P,H_1(m,c))\\)是否成立，若成立，则接收该签名，否则拒绝该签名。

门限签名

若一个群体有\\(n\\)个人，那么至少需要\\(p\\)个人签名才视为有效签名。通常采用共享密钥的方式来实现门限签名，即将密钥分割，例如分成\\(m\\)份，则其中必须有大于\\(p\\)份的子密钥都被选则并且组合到一起，才有可能重现密钥。这种数字签名在密钥托管中广泛应用。

代理签名

密钥所有者可以将签名权利授予第三方，获得签名权利的第三方可以进行数字签名，

双重签名

1983年，Itakura等提出多重签名方案，该方案原理是多个签名者对同一份文件进行签名操作。

同态签名

2001年，Rivest提出同态签名，是指在没有签名私钥的情况下，允许任何实体对已认证的数据进行同态运算操作生成新数据，并得到新数据的有效签名。同态签名根据同态运算函数分类，可以分为线性同态签名、多项式函数同态签名和全同态签名。

参考

1. 数字签名技术综述-杨雪菲
2. 群签名综述-程小刚
3. 部分盲签名综述-李明祥
4. 同态签名研究综述-吴华麟

EIP-712签名介绍以及使用hardhat实现

文章目录

• 简介
• 结构解析
• 签名并验证
• 注意事项

简介

EIP-712是一种高级安全的交易签名方法。使用该标准不仅可以签署交易并且可以验证签名，而且可以将数据与签名以用户可见内容的方式一起传递到智能合约中，并且可以根据该数据验证签名以了解签名者是否是实际发送该签名的人要在交易中调用的数据。

EIP-712提出了数据的标准结构和从结构化消息生成散列的定义过程。然后使用此散列生成签名。通过这种方式，为发送交易生成的签名与为验证身份或任何其他目的生成的签名之间就有了明显的区别。EIP-712草案将签名方案背后的动机表述为:

提高链上使用的链下消息签名的可用性。我们看到越来越多的人采用链下消息签名，因为它节省了gas，减少了区块链上的交易数量。

结构解析

EIP712签名包含三个部分：domain，types和data，以下面的代码为例：其中domain主要用来区分针对不同合约的签名，共包含合约名称(name)、版本号(version)、链ID(chainId)、合约地址(verifyingContract)和盐(salt)五个可选择的部分，types部分限定了需要签名的函数为listNFTwithSig（注意合约中的函数名可以开头不大写，但是签名内容中的函数名必须开头大写）并限定了函数的五个参数与其数据类型，data部分给函数中的参数赋值

    const message = 
        domain: 
            name: "NFTMarket",
            version: "1.0",
            chainId: chainId,
            verifyingContract: marketContract.address
        ,
        types: 
            ListNFTwithSig: [
                name: "_NFTContract", type: "address",
                name: "_tokenId", type: "uint256",
                name: "_price", type: "uint256" ,
                name: "nonce", type: "uint256" ,
                name: "deadline", type: "uint256"
            ],
        ,
        data: 
            _NFTContract: nftContract.address,
            _tokenId: 4,
            _price: 100,
            nonce: 0,
            deadline: 100,
        
    ;

签名并验证

演示代码均在Ubuntu中实现，需要系统提前安装好最新版的node.js，如果没有安装或者版本低的话参照这篇博文安装或更新node.js
安装好之后，新建一个文件夹，在文件夹下新建终端，输入以下命令安装hardhat模块

npm install --save-dev hardhat

输入以下命令初始化hardhat环境

npx hardhat

按四次回车初始化js部署环境。

等所有模块下载好之后进入scripts文件夹下新建文件run.js，将以下代码输入其中

const main = async () => 
    const [guy, randomGuy] = await hre.ethers.getSigners();
    console.log('Guy\\'s address:', guy.address);

    const marketContractFactory = await hre.ethers.getContractFactory("NFTMarket");
    const marketContract = await marketContractFactory.deploy();
    console.log("Contract deployed to:", marketContract.address);
    const chainId = await guy.getChainId(); // 31337
    const nftContract = '0x5fbdb2315678afecb367f032d93f642f64180aa3';
    const message = 
        domain: 
            name: "NFTMarket",
            version: "1.0",
            chainId: chainId,
            verifyingContract: marketContract.address
        ,
        types: 
            ListNFTwithSig: [
                name: "_NFTContract", type: "address",
                name: "_tokenId", type: "uint256",
                name: "_price", type: "uint256" ,
                name: "nonce", type: "uint256" ,
                name: "deadline", type: "uint256"
            ],
        ,
        data: 
            _NFTContract: nftContract,
            _tokenId: 0,
            _price: 100,
            nonce: 0,
            deadline: 100,
        
    ;
	
    console.log(message.domain, message.data);

    // 得到一条哈希
    const sign = await guy._signTypedData(message.domain, message.types, message.data);
    console.log(sign);

    // 从哈希中提取v, r, s
    const sig = ethers.utils.splitSignature(sign);
    console.log(sig.v, sig.r, sig.s);
	
	// 在js中验证签名
    const recoveredAddress = ethers.utils.verifyTypedData(message.domain, message.types, message.data, sig);

    console.log('signer add in js file:', recoveredAddress);

	// 在合约中验证签名
    const _listWithSig = await marketContract.connect(randomGuy).listNFTwithSig(nftContract, 0, 100, 100, sig.v, sig.r, sig.s);
    await _listWithSig.wait();


const runMain = async () => 
    try 
        await main();
        process.exit(0);
    
    catch(error) 
        console.log(error);
        process.exit(1);
    


runMain();

再到contracts文件夹下新建文件起名eip712.sol，将以下代码输入其中：

//SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

import "hardhat/console.sol";

contract NFTMarket 
    mapping(address => uint256) nonces;
    string version = "1.0";
    string name = "NFTMarket";   //contract name 
    bytes32 public DOMAIN_SEPARATOR;
    // ！注意：参数之间只用逗号隔开，不要额外添加空格，否则会导致验签失败！以下domain separator相同！
    // keccak256("ListNFTwithSig(address _NFTContract,uint256 _tokenId,uint256 _price,uint256 nonce,uint256 deadline)")
    bytes32 public constant LIST_TYPEHASH = 0x6f8a295cea3edab22428a30506be6fb57d93dd2ba58973d57bb71c48af8fbc7e;

    constructor() 
        uint256 chainId;
        assembly     //buildin assembly to get chainID
            chainId := chainid()
        
        DOMAIN_SEPARATOR = keccak256(
            abi.encode(
                keccak256("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"),
                keccak256(bytes(name)),
                keccak256(bytes(version)),
                chainId,
                address(this)
            )
        );
        // console.log("constructor chainId:", chainId);  //1337
    

    function listNFTwithSig(address _NFTContract, uint256 _tokenId, uint256 _price, uint256 deadline, uint8 v, bytes32 r, bytes32 s) public 
       bytes32 digest = keccak256(
            abi.encodePacked(
                '\\x19\\x01',
                DOMAIN_SEPARATOR,
                keccak256(abi.encode(LIST_TYPEHASH, _NFTContract, _tokenId, _price, nonces[msg.sender]++, deadline))
            )
        );
        address owner = ecrecover(digest, v, r, s);  //获取消息签名者的地址
        console.log(owner);
    

保存好之后在根目录之下执行

npx hardhat run ./scripts/run.js 

输出结果为：
可以看到签名的地址、js中验签的结果和合约中验签的结果均为地址$0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266$

注意事项

1. 如果签名或验签过程中报错$Error:networkdoesnotsupportENS(operation="getResolver",network="unknown",code=UNSUPPORTE{D}_{O}PERATION,version=providers/5.7.2)$，则需要检查代码中地址的格式是否均为$string$；
2. 合约中LIST_TYPEHASH函数变量要和js中的types相吻合，否则会导致验签失败；
3. 合约代码中涉及到$keccak$加密的部分，函数参数之间只能用一个逗号隔开，不能加空格或者其他字符，否则会导致验签失败；
4. 使用内联汇编获取chainId注意格式，最新版本的solidity使用$chainId:=chainid()$而非旧版本的$chainId:=chainid$