1 Introduction
[33] | [18] | [15] | [53] | [6] | [66] | [39] | [32] | |
---|---|---|---|---|---|---|---|---|
Scenario | ||||||||
Coupons | mc
| mc
| mc
| mc
| mc
| mc
| mc
| mc
|
Merchants | mm
| sm
| sm
| sm
| mm
| sm
| mm
| mm
|
Security | ||||||||
Unforgeability | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Coupon reuse avoidance | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Unlinkability | ✗ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Customer anonymity | ✗ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Anonymity revocation | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ | ✓ |
Confidentiality | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ | ✓ |
Merchant Disaffiliation | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ |
Performance | ||||||||
Implementation | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ | ✗ |
Analytical | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ | ✓ | ✓ |
2 Evaluation of existent electronic multicoupon proposals
3 A framework for evaluating multicoupon solutions
3.1 Multicoupon scenario: design and definition
-
Manufacturer (\(\mathcal {MA}\)) entity that wants to use multicoupons as a marketing instrument to attract new customers or to increase loyalty of previous customers.
-
Coupon provider (\(\mathcal {CP}\)) entity in charge of generating and/or distributing multicoupons to customers, on behalf of manufacturers.
-
Customer (\(\mathcal {C}\)) entity who wants to use multicoupons to obtain products or services, with some incentive (discount or gift).
-
Merchant (\(\mathcal {M}\)) entity that provides products or services and accepts coupons from a multicoupon (to be redeemed) from a customer.
-
Setup/agreement all entities in the multicoupon scenario should obtain all required data to operate in the scheme (e.g., obtaining secret parameters for security purposes), or interact with other entities aimed to reach an agreement on the terms of the involvement of each entity. For example, some functionalities are typically delegated from some entity to another one, but always under an agreement between them, e.g., the issuance of multicoupons could be performed by a coupon provider on behalf of a manufacturer if those entities agree.
-
Finish the system must provide mechanisms in order all entities can safely leave the system (remove information from the database, revoke keys, cancel agreements, etc.).
-
Issuing customers obtain multicoupons directly from the coupon provider or, alternatively, from the manufacturer or the merchant.
-
Redeem customers redeem coupons with a merchant to obtain goods or services (with a discount or gift).
-
Validation merchants could require to check the validity of a multicoupon, and thus they should contact with the manufacturer or the coupon provider, before accepting a multicoupon redeemed from a customer.
-
Clearing merchants send all the redeemed coupons to the manufacturer (or the authorized entity, e.g., a coupon provider) to obtain the amount of money agreed with him.
-
Transferring a customer could transfer single coupons (from his multicoupon), or even a complete multicoupon, to another customer.
3.2 Multicoupon deployment: technical alternatives
Own server | SaaS | PaaS | IaaS | |
---|---|---|---|---|
Deploy client apps | ✓ | ✗ | ✓ | ✓ |
Type of applications | Any | Provider-based | Web-based | Any |
Resources scalability | Own | Provider | Provider | Provider |
Performance tests | Local–global | ✗ | Global | Global |
Security control | Own | Provider | Provider-partially | Client |
Examples | – | Google drive [30] | Azure [64] | Amazon EC2 [24] |
-
performance,
-
functionalities,
-
cost of development and deployment, and
-
security.
3.2.1 Server platform
Platform dependent | Platform independent | ||
---|---|---|---|
Native | Hybrid | Web-based | |
Access to libraries | Unlimited | Limited (API) | Limited (web browser) |
Development cost | High | Low | Low |
Client-side operations | Complex | Limited | Screen show based |
Communication type | Not limited | Not limited | Request–response |
Performance | High | Medium | Low |
Security | High | Medium | Low |
3.2.2 Developing client app
3.2.3 Communication technologies
3.2.4 Messages
3.3 Multicoupon evaluation
-
detecting the processes, or functions that can lessen the performance of the scheme,
-
providing homogeneous parameters to compare the efficiency of different solutions.
-
Response time The required time to execute each process must be evaluated. The time required to complete each process depends on many factors; some rely on the design phase (e.g., the choice of cryptographic tools) or in the deployment phase (e.g., selected cryptographic libraries or the message syntax), as already explained in this section. In order to evaluate this metric in different schemes, it is very important to considerer some issues. As different multicoupon proposals can involve different entities and processes, the time of each process must be evaluated properly. For example, the redemption of a coupon by a customer (
redeem
) could require that the merchant must verify the validity of the coupon (validation
). Thus, the total time perceived by the customer must reflect the execution of both processes. -
Network overhead The network resources used by each process are measured as the amount of data transferred by each message (message size). The choice on the syntax to describe messages has clear implications on the messages size (Sect. 3.2.4), and in turn it has an influence on several parameters, such as delay in communications. Moreover, the selected cryptographic tool (to provide different security requirements) may imply that participants must exchange a larger volume of information.
-
Time spent on processing data This refers to the computational and memory access operations, not related to communications. There are several aspects that affect this processing time, such as computational power of mobile devices, efficiency provided by external cryptographic libraries, the used framework for developing.
-
Time spent on encoding data to be sent and decoding received data One of the factors not considered in previous proposals is coding, and as explained in Sect. 3.2.4, this could have clear implications on performance.
-
Time delay due to communications channel Although the best option in terms of coverage, cost, user adoption and devices support, must be considered (as explained in Sect. 3.2.3), the delay in sending and receiving data must be also analyzed. Sometimes, sending short messages may be more feasible than sending fewer messages but longer.
3.4 How to apply the framework
4 Definition of the Hsueh et al. [33] Proposal
4.1 Relevant cryptographic tools
-
\(pk_{i}\) The public key for user i.
-
\(sk_{i}\) The private key for user i.
-
\(Cert_{i}\) The certificate for user i.
-
\(\textit{CertGen}\) An entity i generates a key pair (\(pk_{i}\), \(sk_{i}\)) and requests the authentication of the keys to an authority. At the end of this procedure, a certificate is issued to the requesting entity (\(Cert_{i}\)). This certificate contains information about the identity of the requesting entity and her public key (\(pk_{i}\)).
-
\(\hbox {Sign}_{i} \left( m \right) \) The signer i uses her secret key \(sk_{i}\) to compute a signature on a message \(\left( m \right) \). This procedure provides non-repudiation of the information.
-
\(\textit{Verify}\) A verifier uses the public key \(pk_{i}\) (included in \(Cert_{i}\)) to verify whether the provided signature is valid and made by the correct user (owner of the corresponding \(sk_{i}\)).
-
\(c=\mathbb {E}_{pk_{i}}{ \left[ m \right] }\) A sender encrypts a message \(\left( m \right) \) using the public key of the recipient giving as a result a ciphertext (c). This procedure provides data confidentiality; only the owner of the private key can read the message.
-
\(\mathbb {D}_{sk_{i}}{ \left[ c \right] }\) A recipient decrypts c using her private key.
4.2 Scheme sketch: unifying actors and processes
Setup
, Issuing
, Redeem
, Validation
, Transferring
, and Clearing
.1. Setup
. Although authors do not specify a setup process, all entities \(\mathcal {C}\), \(\mathcal {M}\), \(\mathcal {CP}\) and \(\mathcal {MA}\) should execute this process to receive a public key certificate (\(Cert_{X}\), where \(X= \mathcal {C}, \mathcal {M}, \mathcal {CP}, \mathcal {MA}\)) from a Certification Authority (CA), attesting that a public key (\(pk_{i}\)) belongs to a specific entity. We have included in Fig. 2, as an example, the steps that should be conducted by \(\mathcal {C}\). As we can see, \(\mathcal {C}\) sends a certificate request, and at the end of this process, she obtains the corresponding certificate.2. Issuing
. \(\mathcal {C}\) is allowed to engage with \(\mathcal {CP}\) to issue a signed multicoupon, \( \mathbb {MC} \). Three entities are involved in this process (Fig. 3): \(\mathcal {C}\), \(\mathcal {CP}\), and \(\mathcal {MA}\). Below, we review the structure of a \( \mathbb {MC} \). It consists of the following two elements:-
\( \mathbb {MC}_{\tiny {Sign}} \) It is a signed structure containing: root indexes (\(X_{0},Y_{0}\)), an expiration date (EXD), a mobile customer identification (MUC), and a serial number (\(SN\)).$$\begin{aligned} \mathbb {MC}_{\tiny {Sign}} = \hbox {Sign}_{\mathcal {MA}} \left( X_{0}, Y_{0}, EXD, MUC, SN \right) \end{aligned}$$
-
\( \mathbb {MC}_{x} \) It is the data structure that defines all coupons within a multicoupon. The solution generates iteratively (by means of a hash chain procedure, \(H(X_{i+1})\)\(=X_i\)) p indexes from an initial secret index \(X_{p}\) up to the last index, called root (\(X_{0}\)).$$\begin{aligned} \mathbb {MC}_{x} = X_{p-1}, X_{p-2},\ldots , X_{0}\end{aligned}$$
3. Redeem
. The Redeem
process includes the functionalities of the Validation
process and works as follows (Fig. 4). \(\mathcal {C}\) prepares an array of data filled by the first unused coupon index (\(X_{i}\)), together with the serial number of the multicoupon, and an identifier for the current transaction (\( R_{id} \)), and sends it to \(\mathcal {M}\). \(\mathcal {M}\) forwards this information (plus his identifier, \(ID_{M}\)) encrypted with the public key of \(\mathcal {CP}\), to \(\mathcal {CP}\). \(\mathcal {CP}\) uses \(SN\) to obtain the corresponding \( \mathbb {MC}_{\tiny {Sign}} \), and updates the database of redeemed coupons. Then, \(\mathcal {CP}\) sends \( \mathbb {MC}_{\tiny {Sign}} \) to \(\mathcal {M}\) who checks if \(X_{i}\) provided by \(\mathcal {C}\) belongs to \( \mathbb {MC}_{\tiny {Sign}} \). If so, he sends a proof of redemption to \(\mathcal {C}\) and the process ends.4. Clearing
. \(\mathcal {M}\) can request \(\mathcal {MA}\) a money transfer in exchange of a received coupon from a customer (Fig. 5). To request a clearing, \(\mathcal {M}\) has to provide \(\mathcal {MA}\) with the serial number of the multicoupon, the index identifying the specific coupon in the multicoupon, and the proof sent to \(\mathcal {C}\) at the end of the Redeem
process. If all validations hold, \(\mathcal {MA}\) authorizes a deposit to the account of \(\mathcal {M}\) based on a previous agreement between both parties.5. Transferring
. The owner of a multicoupon (\(\mathcal {C}_{1}\)) can transfer a shareable multicoupon to another customer (\(\mathcal {C}_{2}\)) (Fig. 6). First, \(\mathcal {C}_{1}\) sends the secret index \(Y_{q}\), \(SN\) and \(\mathcal {CP}\)’s public key to \(\mathcal {C}_{2}\). Next, \(\mathcal {C}_{2}\) encrypts her MUC and sends it to \(\mathcal {C}_{1}\), who finally returns this information signed to \(\mathcal {C}_{2}\) as a proof of the transferring.
5 Definition of the Hinarejos et al. [32] proposal
5.1 Relevant cryptographic tools
-
\(pk^{G}\) The group public key
-
\(sk^{G}_{i}\) The secret signing key for user i
-
\(\sigma \) The group signature on a message m
-
\(\textit{KeyGen}^{G}\) The group manager computes a group public key \(\left( pk^{G}\right) \) for a group of n members, and n secret signing keys \(\left( sk^{G}_{i}, \forall i \in \left[ 1,n \right] \right) \) to be assigned to each member within the group.
-
\(\textit{Sign}^{G}\) The signer uses her own secret signing key \(sk^{G}_{\mathcal {C}}\) to compute a signature \(\left( \sigma \right) \) on a message \(\left( m \right) \).
-
\(\textit{Verify}^{G}\) A verifier uses the group public key \(\left( pk^{G}\right) \) to verify whether the provided group signature \(\left( \sigma \right) \) is valid and made by a user who belongs to the group.
-
\(\textit{Open}^{G}\) The group manager traces a signature revealing the real signer’s identity.
-
\(Init^{\mathcal {PBS}}\) Both signer and requester obtain a key pair \(\left( pk_i, sk_i \right) \) from a secure public key cryptosystem (such as RSA).
-
\(Request^{\mathcal {PBS}}\) The requester asks for a partially blind signature to the signer, sending the message to sign \(\left( m \right) \) in a way the signer cannot read it (by blinding data), together with the previously agreed common information \(\left( \Gamma \right) \).
-
\(Sign^{\mathcal {PBS}}\) Upon receipt of data from the requester, the signer uses his secret key to compute a signature on this data \((\sigma ^{'})\) and sends it to the requester.
-
\(Extract^{\mathcal {PBS}}\) The requester unblinds the received signature and obtains the final expression of the partially blind signature \(\left( \sigma \right) \).
-
\(Verify^{\mathcal {PBS}}\) A verifier can check the partially blind signature \(\left( \sigma \right) \) to determine whether it has to be accepted or rejected.
5.2 Scheme sketch: unifying actors and processes
Setup
, Issuing
, Redeem
, Validation
, and Clearing
.1. Setup
Both \(\mathcal {G}\) and \(\mathcal {CP}\) must execute a setup protocol in order to receive requests from the other parties. \(\mathcal {G}\) has to execute the \(\textit{KeyGen}^{G}\) group signature procedure to create a public group key \(\left( pk^{G}\right) \), and the related set of secret signing keys for signers \(\left( sk^{G}_{i}, \forall i \in \left[ 1,n \right] \right) \). Moreover, each customer who wants to use multicoupons has to register her real identity at \(\mathcal {G}\), in order to receive a group key pair \(\left( pk^{G}, sk^{G}_{\mathcal {C}} \right) \) used to sign, and to prove the fact that she actually belongs to the claimed group. During the customer registration (Fig. 7), \(\mathcal {G}\) links the real identity of \(\mathcal {C}\) to the corresponding signing key in order to provide anonymity revocation in case of misbehavior.2. Issuing
Once \(\mathcal {C}\) is registered with \(\mathcal {G}\), she is allowed to engage with \(\mathcal {CP}\) to issue a signed multicoupon, \( \mathbb {MC} \). Before we explain how the Issue
protocol works, we review the structure of \( \mathbb {MC} \) (Fig. 8). It is composed by the two following elements:-
\( \mathbb {MC}_{\omega } \) It is the data structure that defines all coupons within a multicoupon. Therefore, given a number of m coupons, the solution generates iteratively (by means of a hash chain procedure) \(2m + 1\) hash identifiers from an initial random and secret multicoupon seed\(\left( \omega _{seed} \right) \) up to the last hash identifier, called multicoupon identifier\(\left( \omega _{0} \right) \). Then, each coupon \(\left( c_{i} \right) \) is defined as a pair of consecutive hash identifiers, where the left identifier is called payment information\(\left( c^{pay}_{i} = \omega _{2i-1} \right) \) and the right one is called proof information\(\left( c^{proof}_{i} = \omega _{2i} \right) \), for all \(0 < i \le m\) (i denotes the i-th coupon within the set of coupons). \(\mathcal {C}\) has to keep \( \mathbb {MC}_{\omega } \) in secret, with the exception of \(\omega _{0}\), which is part of the public information \( \mathbb {MC}_{{\mathcal {PBS}}} \).
-
\( \mathbb {MC}_{{\mathcal {PBS}}} \) It is the partially blind signature over the multicoupon identifier (\(\omega _{0}\)). The final \( \mathbb {MC}_{{\mathcal {PBS}}} \) also conveys some verification data (\(verif\_data\)), commonly agreed beforehand \(\left( \Gamma \right) \) between \(\mathcal {C}\) and \(\mathcal {CP}\), which defines the multicoupon features. These features can be different depending on the concrete application or service, but it would be common to consider parameters such as the number of coupons within the multicoupon, the value or discount achieved by each coupon, time marks to fix their validity.
Issuing
process is completely anonymous because neither \(\mathcal {CP}\) knows any data about the identity of \(\mathcal {C}\), nor the resulting \( \mathbb {MC} \) contains information related to her identity. Thus, \(\mathcal {C}\) can operate from this moment with her issued \( \mathbb {MC} \) in an anonymous way.
3. Redeem
Now, \(\mathcal {C}\) is ready to redeem (Fig. 10) coupons from her multicoupon to obtain a service from any \(\mathcal {M}\) affiliated to \(\mathcal {CP}\). The Redeem
process is defined by four steps, in which \(\mathcal {C}\) can redeem either single or multiple coupons using a single protocol call. This is an important enhancement from the point of view of computing and networking efficiency, not considered by other authors.Redeem
process works as follows. \(\mathcal {C}\) prepares an array of data \(\left( \hbox {data}_{1} \right) \) filled by the first unused payment information (\(c_{i}^{pay}\)), together with the target \(\mathcal {M}\)’s identifier (\(id_{\mathcal {M}} \)), and an identifier for the current transaction (\(id_{r} \)). Then, \(\mathcal {C}\) signs this data with her secret signing key \(\left( \textit{Sign}^{G}_{\mathcal {C}} \left( \hbox {data}_{1} \right) \right) \), and sends it to \(\mathcal {M}\), who applies some verifications, such as group signature and partially blind signature validations, he checks whether the provided coupon belongs to \( \mathbb {MC} \), and whether it was not previously redeemed, etc. If all verifications are correct, \(\mathcal {M}\) acknowledges it by means of a signature on the provided service (s) and \(\hbox {data}_{1}\) (he communicates that he is committed to the transaction). Then, both \(\mathcal {C}\) and \(\mathcal {M}\) are engaged in a similar exchange as the previous one, by sending the corresponding proof information (\(c_{i}^{proof}\)). If all verifications hold, \(\mathcal {M}\) updates his stored data and acknowledges \(\mathcal {C}\) in a similar way as before. The reuse avoidance can be performed checking whether any single coupon is either in the local database, or in the \(\mathcal {CP}\)’s global database (executing online the Clearing
process).4. Clearing
(online or offline). Similar to [33], the Validation
process is included in another process, in this case, in the Clearing
process. \(\mathcal {M}\) can request \(\mathcal {CP}\) a money transfer to his account balance in exchange of a list of received coupons from customers (Fig. 11). \(\mathcal {M}\) is allowed to claim coupons, either every time a set of them is received from \(\mathcal {C}\) (on-line Clearing
), or when he has a list of received coupons from customers (offline Clearing
).Redeem
process, i.e., \(\hbox {data}_{1}\) during the first step, and \(\hbox {data}_{2}\) during the third step of the Clearing
process. Upon validation, \(\mathcal {CP}\) acknowledges this data telling \(\mathcal {M}\) whether these coupons had been used before or not (reuse detection). If all verifications hold, \(\mathcal {CP}\) authorizes a deposit to the account of \(\mathcal {M}\) with the right amount of money, according to either the number and value of provided coupons, or based on a previous agreement between both parties.
6 Multicoupon solutions implementation
6.1 Prototype environment
6.1.1 Server platform
Issuing
process involves \(\mathcal {C}\) and \(\mathcal {CP}\) for both solutions, but this process also covers the participation of \(\mathcal {MA}\) in [33]. In the same way, the Redeem
process involves both \(\mathcal {C}\) and \(\mathcal {M}\) for both solutions and also \(\mathcal {CP}\) in [33]. Finally, the Clearing
process is the only one in which two servers are involved, where communications are performed between \(\mathcal {M}\) and \(\mathcal {CP}\) in [32] and between \(\mathcal {M}\) and \(\mathcal {MA}\) in [33].6.1.2 Client application
-
Android provides a well-structured API to developers to build applications using the widespread and supported Java language.
-
It offers a wide market of commercial handset devices to test developments.
-
It is supported from a huge community of developers with a large number of resources, examples and so on.
-
Android is open source, and so, anyone can contribute with enhancements.
-
Android is supplied free of charge.
-
A native framework performs better than cross-platform frameworks.
-
Cryptographic operations must be implemented, and these operations can only be implemented with native code.
6.1.3 Communication technology
6.1.4 Messages
6.2 Key distribution
X.509 Certificate Profile
, it can be observed that the definition of the fields does not restrict its use for other data structures.
SubjectPublicKeyInfo
(listing Public Key
Info
) field is used to carry the public key and to identify the algorithm used (e.g., RSA, DSA) [21]. However, this field can contain any ASN.1 type encoded as a string of bits. For the particular case of the BBS group signature, listing ASN.1 Group Public Key
represents the ASN.1 syntax to define the BBS group public key (see Sect. 5.1).
SGSPublicKey
structure can be converted into a bit string accepted as a value of the field subjectPublicKey
in the X.509 standard. The Subject
field defines who is the owner of the public key (who holds the public key). In our case, it is the group identifier instead of a specific user identity. This way, the Subject
field identifies the concrete group instead of linking the signer.algorithm
from the structure SubjectPublicKeyInfo
. However, there is not a standardized value to identify the group public key, although X.509 allows to define new identifiers as needed. To maintain the interoperability, we propose to use the extensions field to specify that this certificate is in fact a group key certificate. This new extension must be defined as critical, i.e., this extension must be understood by any entity in charge of validating the certificate.6.3 Secure storage of credentials
KeyStore
Java class, which exposes methods to store credentials in a secure repository protected by password. This way, only authorized users and applications can access and extract information from the key store after they type the right password.KeyStore
class. Android provides the system key store, which is something like a vault where only authorized users and applications can access stored private data. Unfortunately, for versions before to 4.0 (Ice Cream Sandwich), the system key store is only available for VPN and Wi-Fi authentication procedures. Thus, applications are not granted the access to it. Instead, Android 4.0 and up bring several enhancements that allow applications to access the system key store to keep personal credentials, such as private keys and digital certificates, by means of a new API named KeyChain
[8]. However, it is only available from 4.0 Android version. To preserve compatibility with older devices, we use the standard method based on the KeyStore
class. So, the application saves his own key store on the smart-phone’s storage.
6.4 Libraries
-
Java Bouncy Castle The Java Bouncy Castle library [12] is a very complete Java library that implements cryptographic algorithms and serves as a provider for the JCE (Java Cryptography Extension) framework. The Bouncy Castle library presents a lightweight and comprehensible API suitable for its use in any Java environment. Moreover, it is continuously supported and improved by a large group of developers. The Bouncy Castle library is used along the developed code as a common framework, methodology and provider to use some cryptographic primitives, in addition to build ASN.1 encoding and decoding procedures where they are needed.
-
Spongy Castle Due to class name conflicts, Android does not allow applications to include the official release of Bouncy Castle. It happens in older Android devices due to the differences between the internal version of Bouncy Castle (Android includes an old and trimmed down version of Bouncy Castle), and the last release of the library bundled by the application. However, there is a project called Spongy Castle [61] distributing a renamed version of the library to work around this issue. It renames all the original packages from
org.bouncycastle.*
to the new one space onorg.spongycastle.*
. As a result, all of the features of the last version of Bouncy Castle can be included in any Android version. -
Simple XML Framework for Java The serialization of Java objects into a representation using XML can be a tedious work without using any specialized library. The first considered option was the JAXB (Java Architecture for XML Binding) [41], as it is the Java reference implementation for serializing objects to XML. However, it cannot be used on the Android platform due to the fact that Android does not allow calling to classes belonging the package
javax.xml.*
. As an alternative, we found the Simple XML Framework for Java [60] which is a lightweight but powerful library that provides a high-performance XML serialization and configuration framework for Java. Simple XML Framework works without further configuration or problems on Android, and it does not depend on any other underlying library.
6.5 Customer application and user experience
Device | Entity | Name | CPU | RAM | OS |
---|---|---|---|---|---|
Virtualbox machine |
\(\mathcal {M}\)
| PS (single-core 2.8 GHz) | 1 virtual core | 1 GiB (Last stable) | Debian Linux |
EC2 t1.micro |
\(\mathcal {MA}\)
| CS-1 (\(\approx \) 1.0–1.2 GHz) | 2 EC2 \(\hbox {CU}^{\mathrm{a}}\) | 600 MiB (customized) | AWS Linux |
EC2 t1.micro |
\(\mathcal {CP}\)
| CS-2 (\(\approx \) 1.0–1.2 GHz) | 2 EC2 \(\hbox {CU}^{\mathrm{a}}\) | 600 MiB (customized) | AWS Linux |
HTC desire |
\(\mathcal {C}\)
| Desire (single-core 1 GHz) | Qualcomm snapdragon | 512 MiB (API level 8) | Android 2.2 |
Google Galaxy Nexus |
\(\mathcal {C}\)
| Nexus (dual-core 1.2 GHz) | Texas instruments OMAP | 1 GiB (API level 17) | Android 4.2.2 |
-
Register View This view allows the customer to request the needed credentials. It shows customer terms and conditions of the service, and it allows to start the registration process. At the end of the process, this view stores in a secure way (see Sect. 6.3) the credentials received from a group manager ([32]), or a certification authority ([33]).
-
Issue New MC View If the customer already owns her credentials, she can execute the
Issuing
process (see Fig. 13a). Depending on each particular solution, the consumer could choose some parameters, for example, the number of coupons included in a multicoupon. After that, theIssuing
process starts, and without any more interaction from the customer, the multicoupon is received and stored. -
Redeem View This view allows the customer (in case she already has previously obtained a multicoupon) looking for merchants where multicoupons can be accepted. When a customer is interested in something offered by a particular merchant, she starts the
Redeem
process only clicking a button. In case a customer has more than a single multicoupon stored, the application requests the customer to choose which one has to be redeemed. The application returns the result of the redeem execution. -
Manage MC View This view provides the customer with an interface to manage her multicoupons (see Fig. 13b). Several data can be shown about each multicoupon: how many coupons are remaining, the expiration date, the purchase history, etc.
-
Settings View It allows the customer to configure some application settings, such as install new personal certificates (see Fig. 13c).
-
Log View The application stores all actions performed by the customer. It can be configured to show either informative messages (such as process beginning and finishing events) or more complex information (such as full message contents).
Communication path | Transmission rate (est. avg.) | Latency (est. avg) | ||
---|---|---|---|---|
Origin | Target | Downstream (Mbps) | Upstream (Mbps) | Round-trip (ms) |
CS-1
| PS
|
\(>25\)
|
\(>25\)
|
\(<100\)
|
Customer app (ADSL) | CS-1 /CS-2 |
\(<3\)
|
\(<0.3\)
|
\(>200\)
|
Customer app (3G) | CS-1 /CS-2 | 2–8 | 2–4 |
\(>200\)
|
7 Performance evaluation of the multicoupon solutions
7.1 Test scenario
CS-1
and CS-2
) running a custom Linux OS installation preconfigured by Amazon. Among the available options, we have selected the free tier micro instance (t1.micro
) [5], because it is free of charge and provides a suitable level of resources to obtain consistent performance measures. Both EC2 instances are in different AWS availability zones (AWS-AZ), i.e., they are not physically close, because CS-1
has been deployed in Virgina AWS-AZ (EEUU), while CS-2
instance has been allocated in Frankfourt AWS-AZ (Europe). This way, our testing scenario models a complex production environment where machines may be allocated far away from each other. Besides, we also consider the use of a virtual machine (called PS
) running a Debian Linux OS allocated in a physical server in our corporate network.Issuing
, Redeem
, and Clearing
, and each test is performed 20 times to obtain average measures.7.2 Performance overview: response time and network overhead
Redeem
and Clearing
), the network overhead can be reduced about a 50% using ASN.1 instead of XML to encode messages in [32]. Clearly, the use of the ASN.1 syntax reduces nicely the network overhead, arriving up to 62% for the Issuing
process in [32]. In [33], the use of ASN.1 reduces the overhead about a 13% for all processes. Although this improvement does not seem very significant in [33], it has clear implications on the general efficiency, as discussed below.
Redeem
due to the fact that it comprises the execution of cryptographic operations, such as group signatures (during the first and third steps), as described in Sect. 5.2. Moreover, the response time is very different whether it is considered XML or ASN.1 formats to encode messages. In fact, for each process in both multicoupon schemes, ASN.1 contributes to improve the performance perceived by customers (up to 40% for [32] and 37% for [33]). It is due to shorter messages (Figs. 15 and 16) and its encoding efficiency.
7.3 Analyzing influence factors on performance
-
The time spent on processing data. Here, the values depend on the processing power of each device, mainly CPU and memory.
-
The time spent on encoding data to be sent and decoding received data. We measure this time considering either XML or ASN.1 encoding formats.
-
The time delay due to communications channel. We evaluate the effect of the network access technology used by the customer: Wi-Fi versus 3G.
Issuing
and Redeem
are the processes where customers are involved.
Redeem
process). If we analyze the processes flow of Issuing
and Redeem
, we notice that some encoded messages are encrypted and then forwarded to the manufacturer or the coupon provider. Those encoded messages (in XML are longer than in ASN.1) are encrypted, increasing the computational burden on the scheme.Issuing
process (66% for the Redeem
process) in [32]. Similarly, more than a 60% of the total time in [33] is due to network activities. Therefore, besides the encoding/decoding format, the network throughput (and of course, stability) is a big concern.