A Privacy-Protecting Multi-Coupon Scheme with Stronger Protection Against Splitting

Abstract

Abstract.A multi-coupon (MC ) represents a collection of k coupons that a user can redeem to a vendor in exchange for some goods or services. Nguyen (FC 2006), deepening the ideas of Chen et al. (FC 2005), introduced an unforgeable privacy-protecting MC system with constant complexity for issuing and redemption of MCs, that discourages sharing of coupons through a property called weak unsplittability, where sharing of a single coupon implies sharing of the whole multi-coupon (all-ornothing sharing). Both schemes still lack some features required by many applications in practice, and also stronger forms of unsplittability are desirable. In this paper, we propose a new security model for MC systems with stronger definitions, followed by a concrete realization where single coupons within a MC may represent different goods or services, have independent validity periods, and must be redeemed sequentially ensuring a stronger version of unsplittability compared to all-or-nothing sharing. The complexity of the proposed scheme is linear in k for the generation of multi-coupons and constant for each redeemed single coupon.

Secure Multi-Coupons for Federated Environments: Privacy-Preserving and Customer-Friendly

“…Hence, we need a nonsequential MCS, where the coupons can be redeemed in arbitrary order. However, the scheme of [11] offers nice features that we want to retain, in particular, coupon objects. These allow to have different types of coupons in one MC.…”

“…Here, we adapt the basic framework from [11] to our scenario with a federation of vendors. The involved parties are a set of vendors V and a set of users U, where n V = |V| denotes the number of vendors in the federation.…”

“…If coupon objects are not necessary, ideas from [6] could be used to obtain logarithmic complexity (in k) for Issue, and also logarithmic size of the MC data. Compared to the MCS from [11], one additional SigOnCommit protocol has to be run instead of a local signature generation during Issue. In the Redeem protocol, two additional IDs (V and fid j ) are sent to the vendor in the first step, and we need an extra round to send a commitment to the vendor.…”

“…In the Redeem protocol, two additional IDs (V and fid j ) are sent to the vendor in the first step, and we need an extra round to send a commitment to the vendor. Another difference is that we use non-interactive versions of the protocols during Redeem, which slightly increases efficiency -but this could also be done in the MCS from [11].…”

“…Here, we generalize the adversarial model from [11] to a federation of vendors. The security requirements are defined by games, and it can be shown that our scheme meets these requirements.…”