Maintaining a balance between anonymity and traceability is a fundamental issue in privacy-preserving systems. Isshiki et al. proposed an identity management system based on group signatures in which a service provider anonymously determines whether or not users of the service are legitimate members, and only a bill collector can identify users for the purposes of sending them invoices. It is particularly worth noting that, under the Isshiki system, the service provider is not required to manage personal information such as user lists, which allows the system to outperform other in terms of preserving user privacy and managing personal information leakage risk. It is also noteworthy that the Isshiki system only considers cases in which the bill collector identifies users who have used the service and that, in fact, identified users who ignore invoices can use the service for free. In this paper, we extended the Isshiki system by adding a smart contract-enabled enforcement bill collection functionality. Under this functionality, deposits made by users who do not pay a service fee are automatically transferred to the bill collector. Because of their centralized structure, group signatures are not suitable to blockchain systems, therefore, the proposed system employs accountable ring signatures as building blocks. The privacy-preserving enforced bill collection system is implemented using the accountable ring signature scheme developed by Bootle et al. and Ethereum smart contracts. To reduce the gas costs associated with running smart contracts, the smart contract is not run unless the user ignores an invoice, and basic procedures are run via an off-chain channel. To avoid the use of heavy cryptographic algorithms in carrying out the accountable ring signature scheme for running smart contracts, we employed standard elliptic curve digital signature algorithm (ECDSA) signatures without especially changing the state to be verified in smart contracts.
Group signatures provide signer anonymity through the use of the verification algorithm that checks only whether a signer of a group signature is a member of the group, and traceability through the use of an authority called a group manager or an opener who is only able to identify signers. These anonymity and traceability are important in preserving privacy and accountability. For example, Isshiki et al. proposed a privacy-preserving identity management system using group signatures (hereafter referred to as the Isshiki system). The Isshiki system is shown in Figure 1. Under this system, a bill collector has the role in the group manager. A user of a service is given a signing key of a group signature scheme by the bill collector, generates a group signature as a certificate, and sends it to the service provider. Owing to the anonymity of group signatures, the service provider can only verify whether or not the user is a valid group member and then provide a service. After delivering the service, the service provider sends an invoice (a group signature) to a different entity, called the bill collector, who manages the opening key of group signatures. The bill collector opens the group signature, identifies the user who has used the service, and sends an (actual) invoice to the user. Because group signatures are traceable, there is no group signature that is valid but cannot be traced to a user.
In implementing the Isshiki system, potentially any group signature scheme can be employed. Following a similar system proposed by Camenisch at al., Isshiki et al. further considered the use of revocations when users leave the service or ignore an invoice, and defined a user-revocation manager that revokes users from the system (more precisely it expires users’ signing keys). To make the underlying group signature scheme revocable, Isshiki et al. employed an extension of the Camenisch-Groth revocable group signature scheme. We note that, although the bill collector and user-revocation manager can be the same entity under these schemes, the service provider must be a distinct entity to ensure separation of the tracing ability. It is particularly worth noting that the service provider is not required to manage personal information such as user lists, that eliminates the risk of personal information leakage. Because information leakage incidents are common, the Isshiki system outperforms other in terms of preserving user privacy while managing personal information leakage risk. Isshiki et al. presented their system as an identity management scheme, the Isshiki system can be considered a privacy-preserving bill collection system.
- Membership privacy for fully dynamic group signatures.
AUTHORS: Michael Backes, Lucjan Hanzlik, and Jonas Schneider-Bensch.
ABSTRACT: Group signatures present a compromise between the traditional goals of digital signatures and the need for signer privacy, allowing for the creation of unforgeable signatures in the name of a group which reveal nothing about the actual signer’s identity beyond their group membership. An important consideration that is absent in prevalent models is that group membership itself may be sensitive information, especially if group membership is dynamic, i.e. membership status may change over time. We address this issue by introducing formal notions of membership privacy for fully dynamic group signature schemes, which can be easily integrated into the most expressive models of group signature security to date. We then propose a generic construction for a fully dynamic group signature scheme with membership privacy that is based on signatures with flexible public key (SFPK) and signatures on equivalence classes (SPSEQ). Finally, we devise novel techniques for SFPK to construct a highly efficient standard model scheme (i.e. without random oracles) that provides shorter signatures than even the non-private state-of-the-art from standard assumptions. This shows that, although the strictly stronger security notions we introduce have been completely unexplored in the study of fully dynamic group signatures so far, they do not come at an additional cost in practice.
2.2 Efficiency improvement in group signature scheme with probabilistic revocation
AUTHORS: Nasima Begum and Toru Nakanishi.
ABSTRACT: In group signature schemes, one of the important issues is the member revocation, and lots of revocable schemes have been proposed. Recently, a Group Signature scheme with Probabilistic Revocation (GSPR) is proposed. In GSPR, by employing a novel notion of probabilistic revocation, the computation cost of the revocation check is drastically reduced, although the correctness of the check is with a certain probability. However, in the GSPR scheme, there is another problem: m alias tokens are embedded into the certificate of a member. Then, in signing, each token is used, and O(m) exponentiations are needed to prove that the used token is embedded in the certificate. When m is large, this signing cost including O(m) exponentiations becomes a big problem for powerless mobile devices. In this paper, we propose an extended GSPR scheme where the signing cost is reduced, but the revocation mechanism is exactly the same as the original GSPR scheme. Our main idea is to utilize an efficient pairing-based accumulator with multiplications to embed lots of alias tokens in a certificate. Thus, in the proposed scheme, the signing cost is reduced to only O(m) multiplications instead of O(m) exponentiations.
2.3 Bulletproofs: Short proofs for confidential transactions and more.
AUTHORS: Benedikt B¨unz, Jonathan Bootle, Dan Boneh, Andrew Poelstra, Pieter Wuille, and Gregory Maxwell
ABSTRACT: We propose Bulletproofs, a new non-interactive zero-knowledge proof protocol with very short proofs and without a trusted setup; the proof size is only logarithmic in the witness size. Bulletproofs are especially well suited for efficient range proofs on committed values: they enable proving that a committed value is in a range using only 2 log_2(n)+9 group and field elements, where n is the bit length of the range. Proof generation and verification times are linear in n. Bulletproofs greatly improve on the linear (in n) sized range proofs in existing proposals for confidential transactions in Bitcoin and other cryptocurrencies. Moreover, Bulletproofs supports aggregation of range proofs, so that a party can prove that m commitments lie in a given range by providing only an additive O(log(m)) group elements over the length of a single proof. To aggregate proofs from multiple parties, we enable the parties to generate a single proof without revealing their inputs to each other via a simple multi-party computation (MPC) protocol for constructing Bulletproofs. This MPC protocol uses either a constant number of rounds and linear communication, or a logarithmic number of rounds and logarithmic communication. We show that verification time, while asymptotically linear, is very efficient in practice. The marginal cost of batch verifying 32 aggregated range proofs is less than the cost of verifying 32 ECDSA signatures. Bulletproofs build on the techniques of Bootle et al. (EUROCRYPT 2016). Beyond range proofs, Bulletproofs provide short zero-knowledge proofs for general arithmetic circuits while only relying on the discrete logarithm assumption and without requiring a trusted setup. We discuss many applications that would benefit from Bulletproofs, primarily in the area of cryptocurrencies. The efficiency of Bulletproofs is particularly well suited for the distributed and trustless nature of blockchains. The full version of this article is available on ePrint.
2.4 Hawk: The Blockchain Model of Cryptography and Privacy-Preserving Smart Contracts
ABSTRACT: Emerging smart contract systems over decentralized cryptocurrencies allow mutually distrustful parties to transact safely without trusted third parties. In the event of contractual breaches or aborts, the decentralized blockchain ensures that honest parties obtain commensurate compensation. Existing systems, however, lack transactional privacy. All transactions, including flow of money between pseudonyms and amount transacted, are exposed on the blockchain. We present Hawk, a decentralized smart contract system that does not store financial transactions in the clear on the blockchain, thus retaining transactional privacy from the public’s view. A Hawk programmer can write a private smart contract in an intuitive manner without having to implement cryptography, and our compiler automatically generates an efficient cryptographic protocol where contractual parties interact with the blockchain, using cryptographic primitives such as zero-knowledge proofs. To formally define and reason about the security of our protocols, we are the first to formalize the blockchain model of cryptography. The formal modeling is of independent interest. We advocate the community to adopt such a formal model when designing applications atop decentralized blockchains.
2.5 Toward fairness of cryptocurrency payments.
AUTHORS: Jian Liu, Wenting Li, Ghassan O. Karame, and N. Asokan.
ABSTRACT: Motivated by the great success and adoption of Bitcoin, a number of cryptocurrencies such as Litecoin, Dogecoin, and Ethereum are becoming increasingly popular. Although existing blockchain-based cryptocurrency schemes can ensure reasonable security for transactions, they do not consider any notion of fairness. Fair exchange allows two players to exchange digital “items,” such as digital signatures, over insecure networks fairly, so that either each player gets the other’s item, or neither player does. Given that blockchain participants typically do not trust each other, enabling fairness in existing cryptocurrencies is an essential but insufficiently explored problem. In this article, we explore the solution space for enabling the fair exchange of a cryptocurrency payment for a receipt. We identify the timeliness of an exchange as an important property especially when one of the parties involved in the exchange is resource-constrained. We introduce the notion of strong timeliness for a fair exchange protocol and propose two fair payment-for-receipt protocol instantiations that leverage functionality of the blockchain to achieve strong timeliness. We implement both and compare their security and efficiency.
3.1 EXISTING SYSTEM:
Isshiki et al. proposed an identity management system based on group signatures in which a service provider anonymously determines whether or not users of the service are legitimate members, and only a bill collector can identify users for the purposes of sending them invoices. It is particularly worth noting that, under the Isshiki system, the service provider is not required to manage personal information such as user lists, which allows the system to outperform other in terms of preserving user privacy and managing personal information leakage risk. It is also noteworthy that the Isshiki system only considers cases in which the bill collector identifies users who have used the service and that, in fact, identified users who ignore invoices can use the service for free.
3.1.1 DISADVANTAGES OF EXISTING SYSTEM:
- It allows the system to outperform other in terms of preserving user privacy and managing personal information leakage risk.
- In fact, identified users who ignore invoices can use the service for free.
- PROPOSED SYSTEM:
- we present the proposed privacy-preserving enforced bill collection system. The system comprises three entities: user, service provider, and bill collector. The service provider verifies a certificate (a ring signature) and provides a service. As in the Isshiki system, service providers have no personal data. The bill collector identifies users who have used the service and sends invoices to them. If a user does not pay a fee, the fee is automatically or forcibly transferred to the bill collector via the smart contract. The bill collector is assumed to send no illegal charges to users who do not use the service, and services are always provided by the service providers (as, otherwise, the system would not be used). We note that ring signatures are sent via an off-chain channel because the user address becomes public when the transaction is issued, which detracts from anonymity. We also note that we do not consider anonymity when a fee is forcibly collected via a smart contract.
Security Requirements: As in the Isshiki system, we assume that the service provider and bill collector do not collude with each other and follow the protocol description (i.e., that they are semi-honest entities).
Our security requirements are as follows:
• User Anonymity: No one, except for the bill collector, can identify a user from a certificate.
• Certificate Unforgeability: No one can modify/forge a certificate.
• Collection Correctness: Each fee is correctly collected from each user by the bill collector even if the user ignores a payment request.
- ADVANTAGES OF PROPOSED SYSTEM:
- we employed standard elliptic curve digital signature algorithm (ECDSA) signatures without especially changing the state to be verified in smart contracts.
3.3 SYSTEM REQUIREMENTS:
The functional requirements or the overall description documents include the product perspective and features, operating system and operating environment, graphics requirements, design constraints and user documentation.
The appropriation of requirements and implementation constraints gives the general overview of the project in regards to what the areas of strength and deficit are and how to tackle them.
- Python idel 3.7 version (or)
- Anaconda 3.7 ( or)
- Jupiter (or)
- Google colab
Minimum hardware requirements are very dependent on the particular software being developed by a given Enthought Python / Canopy / VS Code user. Applications that need to store large arrays/objects in memory will require more RAM, whereas applications that need to perform numerous calculations or tasks more quickly will require a faster processor.
- Operating system : windows, linux
- Processor : minimum intel i3
- Ram : minimum 4 gb
- Hard disk : minimum 250gb
3.4 FUNCTIONAL REQUIREMENTS
3.Training And Testing
3.5 NON FUNCTIONAL REQUIREMENTS
NON-FUNCTIONAL REQUIREMENT (NFR) specifies the quality attribute of a software system. They judge the software system based on Responsiveness, Usability, Security, Portability and other non-functional standards that are critical to the success of the software system. Example of nonfunctional requirement, “how fast does the website load?” Failing to meet non-functional requirements can result in systems that fail to satisfy user needs. Non- functional Requirements allows you to impose constraints or restrictions on the design of the system across the various agile backlogs. Example, the site should load in 3 seconds when the number of simultaneous users are > 10000. Description of non-functional requirements is just as critical as a functional requirement.
- Usability requirement
- Serviceability requirement
- Manageability requirement
- Recoverability requirement
- Security requirement
- Data Integrity requirement
- Capacity requirement
- Availability requirement
- Scalability requirement
- Interoperability requirement
- Reliability requirement
- Maintainability requirement
- Regulatory requirement
- Environmental requirement
3.6 SYSTEM STUDY
The feasibility of the project is analyzed in this phase and business proposal is put forth with a very general plan for the project and some cost estimates. During system analysis the feasibility study of the proposed system is to be carried out. This is to ensure that the proposed system is not a burden to the company. For feasibility analysis, some understanding of the major requirements for the system is essential.
Three key considerations involved in the feasibility analysis are
- ECONOMICAL FEASIBILITY
- TECHNICAL FEASIBILITY
- SOCIAL FEASIBILITY
This study is carried out to check the economic impact that the system will have on the organization. The amount of fund that the company can pour into the research and development of the system is limited. The expenditures must be justified. Thus the developed system as well within the budget and this was achieved because most of the technologies used are freely available. Only the customized products had to be purchased.
This study is carried out to check the technical feasibility, that is, the technical requirements of the system. Any system developed must not have a high demand on the available technical resources. This will lead to high demands on the available technical resources. This will lead to high demands being placed on the client. The developed system must have a modest requirement, as only minimal or null changes are required for implementing this system.
The aspect of study is to check the level of acceptance of the system by the user. This includes the process of training the user to use the system efficiently. The user must not feel threatened by the system, instead must accept it as a necessity. The level of acceptance by the users solely depends on the methods that are employed to educate the user about the system and to make him familiar with it. His level of confidence must be raised so that he is also able to make some constructive criticism, which is welcomed, as he is the final user of the system.
4.1 SYSTEM ARCHITECTURE:
- SERVICE PROVIDER
- BILL COLLECTOR
In this paper, we proposed a privacy-preserving enforced bill collection system that supports a functionality for forcibly collecting service fees from users. The proposed system is based on the use of accountable ring signatures and smart contracts.
In future work, it would be interesting to enhance our system in terms of privacy by, for example, providing membership privacy using the fully dynamic group signature scheme developed by Backes et al. It would also be interesting to develop a bill collection method in which the service fee is collected from users without identifying them, for example, through the use of anonymous crypto assets such as Monero or Zcash.
1.ethereumjs-util. 7.0.7, 2020-10-15, https://github.com/ethereumjs/ ethereumjs-util.
2. Monero. https://getmonero.org.
3. Testnet Ropsten (ETH) blockchain explorer. https://ropsten.etherscan.io/.
4. Zcash. https://z.cash/.
5.Nuttapong Attrapadung, Keita Emura, Goichiro Hanaoka, and Yusuke Sakai. A revocable group signature scheme from identity-based revocation techniques: Achieving constant-size revocation list. In Applied Cryptography and Network Security, pages 419–437, 2014.
6. Nicola Atzei, Massimo Bartoletti, Tiziana Cimoli, Stefano Lande, and Roberto Zunino. SoK: Unraveling bitcoin smart contracts. In POST, pages 217–242, 2018. 7. Michael Backes, Lucjan Hanzlik, and Jonas Schneider-Bensch. Membership privacy for fully dynamic group signatures. In ACM CCS, pages 2181–2198. ACM, 2019.
8. Nasima Begum and Toru Nakanishi. Efficiency improvement in group signature scheme with probabilistic revocation. J. Inf. Process., 27:508– 516, 2019.
9. Mihir Bellare, Haixia Shi, and Chong Zhang. Foundations of group signatures: The case of dynamic groups. In CT-RSA, pages 136–153, 2005.
10. Daniel J. Bernstein. Curve25519: New Diffie-Hellman speed records. In Public Key Cryptography, pages 207–228, 2006.
11. Dan Boneh and Hovav Shacham. Group signatures with verifier-local revocation. In ACM CCS, pages 168–177, 2004.
12. Jonathan Bootle, Andrea Cerulli, Pyrros Chaidos, Essam Ghadafi, and Jens Groth. Foundations of fully dynamic group signatures. In Applied Cryptography and Network Security, pages 117–136, 2016.
13. Jonathan Bootle, Andrea Cerulli, Pyrros Chaidos, Essam Ghadafi, Jens Groth, and Christophe Petit. Short accountable ring signatures based on DDH. In ESORICS, pages 243–265, 2015.
14. Benedikt B¨unz, Shashank Agrawal, Mahdi Zamani, and Dan Boneh. Zether: Towards privacy in a smart contract world. In Financial Cryptography and Data Security, pages 423–443, 2020.
15. Benedikt B¨unz, Jonathan Bootle, Dan Boneh, Andrew Poelstra, Pieter Wuille, and Gregory Maxwell. Bulletproofs: Short proofs for confidential transactions and more. In IEEE Symposium on Security and Privacy, pages 315–334, 2018.