On Locational Privacy in the Absence of Anonymous Payments

Abstract

In this paper we deal with the situation that in certain contexts vendors have no incentive to implement anonymous payments or that existing regulation prevents complete customer anonymity. While the paper discusses the problem also in a general fashion, we use the recharging of electric vehicles using public charging infrastructure as a working example. Here, customers leave rather detailed movement trails, as they authenticate to charge and the whole process is post-paid, i.e., are billed after consumption. In an attempt to enforce transparency and give customers the information necessary to dispute a bill they deem inaccurate, Germany and other European countries require to retain the ID of the energy meter used in each charging process. Similar information is also retained in other applications, where Point of Sales terminals are used. While this happens in the customers’ best interest, this information is a location bound token, which compromises customers’ locational privacy and thus allows for the creation of rather detailed movement profiles. We adapt a carefully chosen group signature scheme to match these legal requirements and show how modern cryptographic methods can reunite the, in this case, conflicting requirements of transparency on the one hand and locational privacy on the other. In our solution, the user’s identity is explicitly known during a transaction, yet the user’s location is concealed, effectively hindering the creation of a movement profile based on financial transactions.

Appendices

Appendix 1: Implementation Details

The current source code is a makefile project, written in C. We chose the language C, as the external routines and the libraries we rely on are also written in C, hence the whole project and its dependencies are written in one language. We implemented XSGS as a library. This XSGS library uses the GNU Multiple Precision Arithmetic Library1⁴² for the basic arithmetic operations, the Pairing-Based Cryptography Library2⁴³ (PBC) for the curve and pairing-based arithmetic operations, the optimized reference implementation of the authors for the SHA3 hash algorithm (Keccak3) and the OpenSSL Library4 for RSA signature and certificate support.

At compile time one can choose between the TCMalloc Library⁴⁴ for a fast and multithreaded malloc() or the GNU C Library memory allocation, which will be linked to the XSGS library.

Appendix 2: Cryptographic Parameters

The PBC library defines a variety of pairing types, of which our XSGS implementation uses either type D, F, or G, respectively. The type can be chosen at compile time. The group order is ~300 bits, the curve parameters are as follows: r > = 160, q >=1024/k, k = 6 (type D) 12 (type F) 10 (type G).

Where Paillier’s operations are used, the modulus is of 1024 bit; RSA can by chose at compile time to use key lengths of either 1024, 2048, or 4096. The cryptographic hash function used throughout the XSGS implementation is the SHA3 contest winner Keccak with 256 bit hash length.