A Multi-Party Functional Signatures Scheme for Private Blockchain
Abstract
:1. Introduction
- This paper proposes a novel scheme that combines functional signatures and multi-party ECDSA signatures to create a multi-party functional signature for private blockchains. Compared to the previous scheme, the proposed scheme ensures that each part of the transaction is verified. Moreover, in cases where the aggregate signature of the entire transaction cannot be verified, this scheme identifies the precise portion of the transaction where signature authentication fails rather than rejecting the transaction in its entirety.
- This paper ensures the security and authenticity of function f in the function signature by embedding it in a smart contract using blockchain’s smart contract technology.
- This paper provides proof of the security of the constructed scheme. Under the existence of the unforgeability of ECDSA signatures, the proposed scheme is secure even if it is corrupted in parties (assuming a total of n parties).
2. Related Work
3. Preliminaries
3.1. ECDSA Signature
- Setup: On inputting the security parameter, the system outputs public parameters param = {E, , G, P, p, q, H}, where E is an elliptic curve defined over a finite field , p is a prime and G is an additive cyclic group consisting of all points in E; P is the generator of the group G, and q is the prime order of the group G. Finally, H is a cryptographic hash function denoted as and Z is the field consisting of the set of integers {1, 2, …, q − 1}.
- KeyGen: On inputting the public parameter param, the following two steps generate the signed public–private key pair.
- Choose a random integer as secret key.
- Compute the as public key.
- SigGen: On inputting the public parameter param, the signing secret key d, and the message m, output the signature of message m . The steps for generating a signature are as follows.
- Randomly select integer .
- Compute , where R is a point on the elliptic curve E.
- Compute , and if/when r is 0, return to the first step to reselect k.
- Compute , where .
- Output the generated signature , where .
- Verify: On inputting the message m to be verified and it’s signature , output 0 or 1 (0 means failure, 1 means success). The steps for verifying a signature are as follows.
- Check whether the integers r and s belong to . If they do not belong, terminate the verification; otherwise, execute next step.
- Compute .
- Compute to verify signature.
- When , output 1, otherwise output 0.
3.2. Functional Signatures
- FS.Setup () On inputting a parameter , it can output the master signing key Msk and the master verification key Mvk.
- FS.KeyGen(Msk,f) On inputting the master signing key and a function , it outputs the signing key for f.
- FS.Sign(f,,m) On inputting the function , generated signing key , and the message that needs to be signed, it outputs the pair signature .
- FS.Verify(Mvk,,) On inputting the master verification key Mvk, a message and a signature , where , it outputs 1 or 0, where 1 indicates that the signature is valid.
3.3. Security Definition
- The challenger runs FS.Setup() and sends Mvk to adversary .
- Adversary is allowed to query the key generation oracle and a signing oracle; they are noted as and . The challenger initializes a dictionary indexed by tuples , which contained the signing keys: FS.KeyGen(Msk,f). This dictionary records the keys that were previously generated in the Unforgivability game. and are defined as follows:
- -
- : On inputting , the challenger runs as follows:
- 1.
- If there is an entry for in the dictionary, then the corresponding key is output.
- 2.
- Otherwise, by FS.KeyGen(Msk,f) sample a fresh key, add the to the dictionary in order to update it, and output .
- -
- : On inputting , the challenger runs as follows:
- 1.
- If there is an entry for in the dictionary, then the corresponding signature FS.Sign(f,,m) is output.
- 2.
- Otherwise, by FS.KeyGen(Msk,f) sample a fresh key, add the to the dictionary, and the corresponding signature FS.Sign(f,,m) is output.
- -
- The adversary wins the game if it can output a signature such that:
- 1.
- FS.Verify(Mvk,) = 1.
- 2.
- There does not exist m such that for any f that was sent as a query to the key generation oracle .
- 3.
- There does not exist a that was queried to the signing oracle and .
3.4. Smart Contract
4. Proposed System Model and Multi-Party Functional Signatures Method
4.1. System Model Framework
- Gateway nodes manage the function f of functional signatures using smart contracts.
- Each mining node checks different of , divided by function f of functional signatures. After that, the signature corresponding to the respective is generated. Gateway nodes manage the function f of functional signatures using smart contracts.
- After receiving all partial transaction signatures , an aggregated signature is generated and stored in the block header.
- Full nodes can search for all the transaction signatures stored in the blockchain.
- Validator nodes check the correctness of the queried signature. Once an error occurs in the signature stored in the block header, the partial transaction signature stored in the block body can be queried and checked.
4.2. Smart Contract Settings and Proposed Concrete Scheme
4.2.1. Smart Contract Design
- authorizeAccount: When deploying the smart contract, the gateway nodes collect all legal account identity information. All these accounts consist of authorizeAccount.
- functionSet: The set stores all the functions f of functional signatures. Functions f of functional signatures that do not belong to functionSet are prohibited from being invoked.
- ct.sender: This invokes the contract’s account.
- f.Set: All functions that are stored in functionSet have a set f.Set, and some accounts are stored in it. If ct.sender does not belong to f.Set, it cannot use f.
Algorithm 1: invokeF |
Input: f Output: bool if ct.sender does not exist in authorizeAccount then throw;end if f does not exist in functionSet then return false;else
if ct.sender does not exist in f.Set then return false; else return true; end end |
Algorithm 2: addUser(f,) |
Input: f, Output: bool if f does not exist in functionSetthen return false; else
if ct.sender has exist in f.Set then return false; else f.set[ct.sender] ⇐ true return true; end end |
Algorithm 3: deleteUser(f,) |
Input: f, Output: bool if f does not exist in functionSet then return false; else
if ct.sender has not exist in f.Set then return false; else f.set[ct.sender] ⇐ false return true; end end |
4.2.2. Concrete Multi-Party Functional Signatures Scheme
- MFS.Setup: The full node first selects the security parameter and runs the Setup algorithm of the ECDSA signature to generate public parameters = {E, , G, P, p, q, H}, then randomly selects as the master private key Msk and computes the master public key as Mvk. The full node chooses n random numbers and computes , where satisfies .
- MFS.KeyGen: Each mining node initiates a request to the full node, and then the full node sends the to mining node by a secure channel. Each mining node selects randomly to send to the full node by Diffie–Hellman key exchange. The full node computes and , where k is stored in the full node and is sent to each mining node . Let be chosen randomly by the full node, and is computed byEach mining node sends H() to the full node, where is the identification information of node . The full node stores securely. The full node randomly selects and computes . Two nodes and receive and , respectively, by Diffie–Hellman key exchange, where they satisfyEach mining node computesThe public key of mining node is . Each mining node gets by Diffie–Hellman key exchange as a part of the private key sk and invokes a smart contract to verify the authenticity of . The full node signs for by the Msk and SigGen algorithms of the ECDSA signature, the signature of is noted as . Creating the certificate , the private key of node is .
- MFS.Sign: To sign the message m, all the nodes start to get e = H(m) and computeThe signature generated by each mining node is , where . The full node receives from all nodes and calculates using the internally saved . Finally, the output is the .
- MFS.Verify: For overall transactions, the data of the transactions verifier can verify signature Sig by using the Verify algorithm of the ECDSA signature. If the data of transactions verifier needs to check the authenticity of the signature of node , he can check that:
- 1.
- ;
- 2.
- Whether is valid by the Verify algorithm of the ECDSA signature and Mvk.
- Correctness: The correctness of the signature for node is guaranteed by the ECDSA signature algorithm. The following equation determines the correctness of Sig:
5. Security Analysis
- For each , is a valid signature of m under the verification key .
- For each , is a valid signature of under the master public key Mvk.
- for all i.
- has not sent a query of form for all i to the oracle , and is in the range of the .
- has not sent a query of form for all i to the oracle .
- Type I forgery: The tuples satisfy that has not already been signed under the master key Mvk for queries from to the oracles and .
- Type II forgery: The tuples satisfy that has been signed under the master key Mvk for queries from to the oracles and .
- Case 1: b = 1: guesses that will produce a Type I forgery:
- :
- -
- If there exists an entry for the tuple in the dictionary, then output the corresponding value .
- -
- Otherwise, randomly selects as , and computes as ; obtains from his oracle, and return to . He also updates the dictionary by adding the entry .
- :
- -
- If there exists an entry for the tuple in the dictionary, it has the . He can generate a signature . Because he knows all about the corrupted nodes, he can output , where and .
- -
- Otherwise, randomly selects as , and computes as ; obtains from his oracle, and updates the dictionary by adding the entry . He then generates Sig by , and outputs , where and .
- Case 2: b = 0: guesses that will produce a Type II forgery:
- :
- -
- If there exists an entry for the tuple in the dictionary with the value CHA, abort.
- -
- If there exists an entry for the tuple in the dictionary with a value that is not CHA, output the key .
- -
- Otherwise, randomly selects as , and computes as ; generates the by himself and returns to . He also updates the dictionary by adding the entry .
- :
- -
- If there exists an entry for the tuple in the dictionary, . He generates a signature Sig by himself, and outputs , where and .
- -
- If there is no the tuple in the dictionary, and , generates a new key pair by randomly choosing the as and computing as ; signs to generate by using Msk, and sets tuple in his dictionary to . He then generates the signature Sig on message m by using Msk, outputs , where and , and sets .
- -
- If there is no tuple in the dictionary and , or if the tuple in the dictionary is set to CHA, then generates the signature of m under by oracle , , computes by using Msk, and outputs , where and . If there is no tuple in the dictionary, sets it to CHA. Then .
6. Results
6.1. Complexity Analysis
- : Time costs to run one hash function;
- : Time costs of running one multiplication operation in additive group G;
- : Time costs of running one multiplication operation in field ;
- : Time costs of running one addition operation in field ;
- : Time costs of running one ;
- : Time costs for full node to communicate with nodes;
- : Time costs of running one extended Euclidean algorithm;
- : Time costs of running one smart contract;
- : Time costs of running one Diffie–Hellman key exchange.
6.2. Implement
6.3. The Limitations of the Study
7. Conclusions
Author Contributions
Funding
Institutional Review Board Statement
Informed Consent Statement
Data Availability Statement
Conflicts of Interest
References
- Fanning, K.; Centers, D.P. Blockchain and its coming impact on financial services. J. Corp. Account. Financ. 2016, 27, 53–57. [Google Scholar] [CrossRef]
- Nguyen, Q.K. Blockchain-a financial technology for future sustainable development. In Proceedings of the 2016 3rd International Conference on Green Technology and Sustainable Development (GTSD), Kaohsiung, Taiwan, 24–25 November 2016; pp. 51–54. [Google Scholar]
- Treleaven, P.; Brown, R.G.; Yang, D. Blockchain technology in finance. Computer 2017, 50, 14–17. [Google Scholar] [CrossRef]
- Saxena, S.; Bhushan, B.; Ahad, M.A. Blockchain based solutions to secure IoT: Background, integration trends and a way forward. J. Netw. Comput. Appl. 2021, 181, 103050. [Google Scholar] [CrossRef]
- Shaukat, K.; Alam, T.M.; Hameed, I.A.; Khan, W.A.; Abbas, N.; Luo, S. A review on security challenges in internet of things (IoT). In Proceedings of the 2021 26th International Conference on Automation and Computing (ICAC), Portsmouth, UK, 2–4 September 2021; pp. 1–6. [Google Scholar]
- Benisi, N.Z.; Aminian, M.; Javadi, B. Blockchain-based decentralized storage networks: A survey. J. Netw. Comput. Appl. 2020, 162, 102656. [Google Scholar] [CrossRef]
- Nasir, A.; Shaukat, K.; Khan, K.I.; Hameed, I.A.; Alam, T.M.; Luo, S. What is core and what future holds for blockchain technologies and cryptocurrencies: A bibliometric analysis. IEEE Access 2020, 9, 989–1004. [Google Scholar] [CrossRef]
- Nakamoto, S.; Bitcoin, A. A peer-to-peer electronic cash system. Bitcoin 2008, 4. Available online: https://bitcoin.org/bitcoin.pdf (accessed on 11 March 2023).
- Wood, G. Ethereum: A secure decentralised generalised transaction ledger. Ethereum Proj. Yellow Pap. 2014, 151, 1–32. [Google Scholar]
- Shaukat, K.; Alam, T.M.; Luo, S.; Shabbir, S.; Hameed, I.A.; Li, J.; Abbas, S.K.; Javed, U. A review of time-series anomaly detection techniques: A step to future perspectives. In Advances in Information and Communication: Proceedings of the 2021 Future of Information and Communication Conference (FICC); Springer International Publishing: Vancouver, BC, Canada, 2021. [Google Scholar]
- Javed, U.; Shaukat, K.; Hameed, I.A.; Iqbal, F.; Alam, T.M.; Luo, S. A review of content-based and context-based recommendation systems. Int. J. Emerg. Technol. Learn. 2021, 16, 274–306. [Google Scholar] [CrossRef]
- Shaukat, K.; Luo, S.; Varadharajan, V. A novel deep learning-based approach for malware detection. Eng. Appl. Artif. Intell. 2023, 122, 106030. [Google Scholar] [CrossRef]
- Perez, A.T.E.; Rossit, D.A.; Tohme, F.; Vasquez, O.C. Mass customized/personalized manufacturing in Industry 4.0 and blockchain: Research challenges, main problems, and the design of an information architecture. Inf. Fusion 2022, 79, 44–57. [Google Scholar] [CrossRef]
- Kushwaha, S.S.; Joshi, S.; Singh, D.; Kaur, M.; Lee, H.N. Systematic review of security vulnerabilities in ethereum blockchain smart contract. IEEE Access 2022, 10, 6605–6621. [Google Scholar] [CrossRef]
- Shaukat, K.; Luo, S.; Varadharajan, V. A novel method for improving the robustness of deep learning-based malware detectors against adversarial attacks. Eng. Appl. Artif. Intell. 2022, 116, 105461. [Google Scholar] [CrossRef]
- Boyle, E.; Goldwasser, S.; Ivan, I. Functional signatures and pseudorandom functions. In Proceedings of the Public-Key Cryptography–PKC 2014: 17th International Conference on Practice and Theory in Public-Key Cryptography, Buenos Aires, Argentina, 26–28 March 2014; Proceedings 17. pp. 501–519. [Google Scholar]
- Backes, M.; Meiser, S.; Schröder, D. Delegatable functional signatures. In Proceedings of the Public-Key Cryptography–PKC 2016: 19th IACR International Conference on Practice and Theory in Public-Key Cryptography, Taipei, Taiwan, 6–9 March 2016; Proceedings, Part I. pp. 357–386. [Google Scholar]
- Okamoto, T.; Takashima, K. Decentralized Attribute-Based Signatures. In Proceedings of the Public Key Cryptography, Nara, Japan, 26 Feburary–1 March 2013; pp. 125–142. [Google Scholar]
- Lu, H.; Jin, C.; Helu, X.; Zhu, C.; Guizani, N.; Tian, Z. AutoD: Intelligent blockchain application unpacking based on JNI layer deception call. IEEE Netw. 2020, 35, 215–221. [Google Scholar] [CrossRef]
- MacKenzie, P.; Reiter, M.K. Two-party generation of DSA signatures. In Proceedings of the Advances in Cryptology–CRYPTO 2001: 21st Annual International Cryptology Conference, Santa Barbara, CA, USA, 19–23 August 2001; Proceedings 21. pp. 137–154. [Google Scholar]
- Lindell, Y. Fast secure two-party ECDSA signing. In Proceedings of the Advances in Cryptology–CRYPTO 2017: 37th Annual International Cryptology Conference, Santa Barbara, CA, USA, 20–24 August 2017; Proceedings, Part II 37. pp. 613–644. [Google Scholar]
- Castagnos, G.; Catalano, D.; Laguillaumie, F.; Savasta, F.; Tucker, I. Two-party ECDSA from hash proof systems and efficient instantiations. In Proceedings of the Advances in Cryptology–CRYPTO 2019: 39th Annual International Cryptology Conference, Santa Barbara, CA, USA, 18–22 August 2019; Proceedings, Part III 39. pp. 191–221. [Google Scholar]
- Lindell, Y.; Nof, A. Fast secure multiparty ECDSA with practical distributed key generation and applications to cryptocurrency custody. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, Toronto, ON, Canada, 15–19 October 2018; pp. 1837–1854. [Google Scholar]
- Doerner, J.; Kondi, Y.; Lee, E.; Shelat, A. Threshold ECDSA from ECDSA assumptions: The multiparty case. In Proceedings of the 2019 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 19–23 May 2019; pp. 1051–1066. [Google Scholar]
- Gennaro, R.; Goldfeder, S. Fast multiparty threshold ECDSA with fast trustless setup. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, Toronto, ON, Canada, 15–19 October 2018; pp. 1179–1194. [Google Scholar]
- Shaukat, K.; Luo, S.; Varadharajan, V.; Hameed, I.A.; Chen, S.; Liu, D.; Li, J. Performance comparison and current challenges of using machine learning techniques in cybersecurity. Energies 2020, 13, 2509. [Google Scholar] [CrossRef]
- Shaukat, K.; Luo, S.; Varadharajan, V.; Hameed, I.A.; Xu, M. A survey on machine learning techniques for cyber security in the last decade. IEEE Access 2020, 8, 222310–222354. [Google Scholar] [CrossRef]
- Halpin, H.; Piekarska, M. Introduction to Security and Privacy on the Blockchain. In Proceedings of the 2017 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), Paris, France, 26–28 April 2017; pp. 1–3. [Google Scholar]
- Li, X.; Xu, J.; Fan, X.; Wang, Y.; Zhang, Z. Puncturable signatures and applications in proof-of-stake blockchain protocols. IEEE Trans. Inf. Forensics Secur. 2020, 15, 3872–3885. [Google Scholar] [CrossRef]
- Zhu, Y.; Guo, R.; Gan, G.; Tsai, W.T. Interactive incontestable signature for transactions confirmation in bitcoin blockchain. In Proceedings of the 2016 IEEE 40th Annual Computer Software and Applications Conference (COMPSAC), Atlanta, GA, USA, 10–14 June 2016; Volume 1, pp. 443–448. [Google Scholar]
- Mercer, R. Privacy on the blockchain: Unique ring signatures. arXiv 2016, arXiv:1612.01188. [Google Scholar]
- Gong, B.; Cui, C.; Hu, M.; Guo, C.; Li, X.; Ren, Y. Anonymous traceability protocol based on group signature for blockchain. Future Gener. Comput. Syst. 2022, 127, 160–167. [Google Scholar] [CrossRef]
- Kokoris Kogias, E.; Jovanovic, P.; Gailly, N.; Khoffi, I.; Gasser, L.; Ford, B. Enhancing Bitcoin Security and Performance with Strong Consistency via Collective Signing; USENIX Association: Berkeley, CA, USA, 2016. [Google Scholar]
- Zhou, X.; Wu, Q.; Qin, B.; Huang, X.; Liu, J. Distributed bitcoin account management. In Proceedings of the 2016 IEEE Trustcom/BigDataSE/ISPA, Tianjin, China, 23–26 August 2016; pp. 105–112. [Google Scholar]
- Alangot, B.; Suresh, M.; Raj, A.S.; Pathinarupothi, R.K.; Achuthan, K. Reliable collective cosigning to scale blockchain with strong consistency. In Proceedings of the Network and Distributed System Security Symposium (DISS’18), San Diego, CA, USA, 18–21 February 2018; pp. 1932–4537. [Google Scholar]
- Yu, M.; Zhang, J.; Wang, J.; Gao, J.; Xu, T.; Deng, R.; Zhang, Y.; Yu, R. Internet of Things security and privacy-preserving method through nodes differentiation, concrete cluster centers, multi-signature, and blockchain. Int. J. Distrib. Sens. Netw. 2018, 14, 1550147718815842. [Google Scholar] [CrossRef]
- Maxwell, G.; Poelstra, A.; Seurin, Y.; Wuille, P. Simple schnorr multi-signatures with applications to bitcoin. Des. Codes Cryptogr. 2019, 87, 2139–2164. [Google Scholar] [CrossRef]
- Yu, H.; Wang, H. Elliptic curve threshold signature scheme for blockchain. J. Inf. Secur. Appl. 2022, 70, 103345. [Google Scholar] [CrossRef]
- Xiao, Y.; Zhang, P.; Liu, Y. Secure and efficient multi-signature schemes for fabric: An enterprise blockchain platform. IEEE Trans. Inf. Forensics Secur. 2020, 16, 1782–1794. [Google Scholar] [CrossRef]
- Uganya, G.; Baskar, R. Modified Elliptic Curve Cryptography Multi-Signature Scheme to Enhance Security in Cryptocurrency. Comput. Syst. Sci. Eng. 2023, 45, 641–658. [Google Scholar] [CrossRef]
Scheme | Efficiency | Blockchain | Provable Security | Against Collusion Attack |
---|---|---|---|---|
[24] | low | no | yes | no |
[33] | low | yes | uncertain | no |
[34] | low | yes | uncertain | yes |
[37] | high | yes | yes | yes |
[38] | high | yes | yes | no |
[39] | high | yes | yes | yes |
[40] | high | yes | yes | yes |
Mining Node | Full Node | |
---|---|---|
Time costs |
Scheme | Blockchain | Provable Security | Against Collusion Attack | Fine-Grained |
---|---|---|---|---|
[24] | no | yes | no | no |
[33] | yes | uncertain | no | no |
[38] | yes | yes | no | no |
[39] | yes | yes | yes | no |
[40] | yes | yes | yes | no |
our | yes | yes | yes | yes |
Length of FunctionSet | Gas Used | USD ($) |
---|---|---|
5 | 948,328 | 0.973 |
10 | 1,115,115 | 1.144 |
15 | 1,281,915 | 1.315 |
20 | 1,448,660 | 1.486 |
Length of FunctionSet | Function | Gas Used | USD ($) |
---|---|---|---|
5 | invokeF | 64,445 | 0.066 |
addUser | 94,981 | 0.097 | |
deleteUser | 55,675 | 0.057 | |
10 | invokeF | 83,965 | 0.086 |
addUser | 114,502 | 0.117 | |
deleteUser | 75,195 | 0.077 | |
15 | invokeF | 103,486 | 0.106 |
addUser | 134,023 | 0.138 | |
deleteUser | 94,716 | 0.097 | |
20 | invokeF | 123,007 | 0.126 |
addUser | 153,543 | 0.158 | |
deleteUser | 114,237 | 0.117 |
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content. |
© 2023 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).
Share and Cite
Zhou, Q.; Zheng, Y.; Wei, K.; Chen, M.; Zeng, Z. A Multi-Party Functional Signatures Scheme for Private Blockchain. Cryptography 2023, 7, 21. https://doi.org/10.3390/cryptography7020021
Zhou Q, Zheng Y, Wei K, Chen M, Zeng Z. A Multi-Party Functional Signatures Scheme for Private Blockchain. Cryptography. 2023; 7(2):21. https://doi.org/10.3390/cryptography7020021
Chicago/Turabian StyleZhou, Quan, Yulong Zheng, Kaijun Wei, Minhui Chen, and Zhikang Zeng. 2023. "A Multi-Party Functional Signatures Scheme for Private Blockchain" Cryptography 7, no. 2: 21. https://doi.org/10.3390/cryptography7020021