Privacy-preserving solution for vehicle parking services complying with EU legislation

System architecture

Three types of entities interact in our privacy-preserving vehicle parking system:

• Parking Service Provider (PSP): The PSP generates cryptographic parameters and keys. It also registers new users and revokes/identifies the malicious ones. Furthermore, the PSP mediates communication between users and the PLT and enrolls new PLTs in the system. The communication with the PSP takes place fully via an Internet connection. We assume that the PSP is a semi-trusted party which honestly runs the algorithms but could be curious.

• Parking Lot Terminal (PLT): The PLT represents the system controlling access to the specific parking lot. It is responsible for issuing the parking permits to users and verifying the presented parking permits by users. The communication with the PSP takes place via an Internet connection during the parking permit issue phase (reservation parking in the parking lot) and via Bluetooth connection during the parking permit verification phase (accessing the parking lot).

• User Device: The user is represented by its device, typically a smartphone. These devices allow storing users’ parking permits issued by the PLT through the PSP and presenting these permits to the PLT when users access the parking lot. Furthermore, this device holds system parameters, generates and stores user cryptographic keys, communicates with PSP via Internet connection (i.e., Wi-Fi, Long Term Evolution (LTE)) and with PLT via the Bluetooth Low Energy (BLE) interface.

The privacy-preserving parking system with all involved entities and protocols is depicted in Fig. 1. The proposal also involves a trusted third party—IDentity Provider (IDP) that manages user identity and associated identity attributes.

Trust assumptions

We assume that communication between all communication parties is secured. In particular, the communication between users and the PSP and the communication between the PSP and PLTs is secured by Transport Layer Security (TLS) protocol. The whole system is based on a trust chain, i.e., we expect the existence of Public Key Infrastructure (PKI) and trusted certification authorities. Besides the privacy-enhancing protocols used in our parking system in each scenario phase described in the ‘Detailed Description of Our Algorithms’ section, we need to consider also other privacy issues which can impact users privacy:

• Anonymous Payment Methods: The payment to PLT can be done privately by deploying the improved e-payment 3D-Secure protocol (Plateaux et al., 2013) or by using popular wallets on mobile devices that support privacy-preserving cryptocurrencies, i.e., Monero (Noether, 2015), Zcash (Kappos et al., 2018), and DASH (Duffield & Diaz, 2015). The security and privacy of popular Android wallets have been studied in Biryukov & Tikhomirov (2019).

• Anonymous Communications in Wide Area Network (WAN): Privacy-preserving communication in WAN can be achieved by mature onion routing protocols and techniques such as ToR (Dingledine, Mathewson & Syverson, 2004). Then, users are able to privately communicate with PSP via Internet during their registration and issuing parking permit. On one hand, users’ source addresses and actual locations are hidden to PSP and observers because the ToR protocol applies at least three randomly-selected servers (onion routers) as relays and encrypts the communication (creating the onion layers). On the other hand, communication via ToR can cause delays due to encryption operations and using more hops.

• Anonymous Communications in Personal Area Network (PAN): For PAN, one typical technology is Bluetooth Low Energy (BLE). By design, BLE provides a reasonable level of privacy protection with features like address randomization (Cäsar et al., 2022) and it has been widely used in contact tracing for COVID-19, e.g., Tang (2022). Therefore, we can assume that BLE provides a sufficient level of anonymity/privacy guarantee in our application.

• Surveillance Minimization: Surveillance security systems with cameras are usually deployed in parking lots and garages in order to increase security against various physical attacks, vandalism, and thefts. Moreover, some solutions are based on using Automatic Number Plate Recognition (ANPR) or Licence Plate Recognition (LPR) to detect concrete vehicles that prepaid a service. Nevertheless, these camera systems could conflict with users’ privacy and GDPR. Thus, it is necessary to use records and basic functionality of ANPR only for security purposes and not to store records for longer periods or non-permitted tracking.

Scenario phases

Our parking scenario consists of the following phases:

1. Register user phase: The digital identity of the user is created in this phase, as illustrated in Fig. 2. First, the users download the mobile application of the parking system, e.g., using Google Play (see, 1.1. Download mobile parking application). Second, the users use the application to create their; own digital identity in the parking system. To do so, we suggest involving a trusted third party that will manage user identity and associated identity attributes (see, 1.2. Create digital identity (through trusted third party)). This party is called IDentity Provider (IDP). Thanks to using the IDP, we do not need to store sensitive user data, such as name, surname, address, age, gender. Otherwise, these data can directly identify the user and can be a target of cyberattacks. Therefore, we suggest to deploy one from these following methods to create a digital identity in the parking system: When the digital identity of the user is created, the PSP runs the Register algorithm (see, 1.3. Register user). In particular, the PSP generates the user access credential Λ and user secret key sk_U. To do so, the PSP will use group signature (Hajny et al., 2018). The credential and the secret key are sent to the user’s device (see, 1.4. Send user credentials) where they are securely stored (see, 1.5. Store credentials and secret key). Furthermore, the secret key is also stored in the PSP Revocation Database (RD) (see, 1.6. Store secret key). The PSP can use this database to revoke or identify malicious users. The user revocation is possible only in collaboration with the PLT. The user identification requires also the involvement of IDP.

   • Payment card binding: The users have to add their bank cards to the parking application. The PSP does a pre-authorization charge to make sure the payment card used by the user is valid. If so, the PSP will create the digital identity of the user. The digital identity is represented by the payment card number provided by the user. The PSP learns no more information about the user. If the user commits fraud, the PSP will query disclosing the user identity to the bank that issued the payment card.

   • Mobile number binding: The users have to add their phone number to the parking application. The PSP sends an authorization code to this phone number to make sure the phone number provided by the user is valid. If so, the PSP will create the digital identity of the user. The digital identity is represented by the phone number provided by the user. The PSP learns no more information about the user. If the user commits fraud, the PSP will query disclosing the user identity to the mobile operator. In this case, it is necessary to have a registered telephone number, such as in some European Union (EU) countries. For example, all SIM cards in Spain need to be registered by law.

   • Electronic identification (eID) binding: The user has to use trusted Identity Provider (IDP) supported by the PSP and according to the EU electronic identification and trust services (eIDAS) Regulation. For example, in the Czech Republic, we can find the eObanka application. The PSP learns no more information about the user. If the user commits fraud, the PSP will query disclosing the user identity to the organization delivering public digital services in an EU member state.

2. Issue parking permit phase: The parking reservation is made through the PSP. The PSP acts as a gateway between the user and the PLT, as illustrated in Fig. 3. The PSP does not interfere with the Issue algorithm. It only forwards the communication between communicating parties. The Issue algorithm is run between the user device and the PLT. First, the user sends a parking request to the PLT (see, 2.1. Send parking request). Basically, this information is where, when, and for how long the user wants to park. No sensitive, personal, or other linkable data are provided. This information is sent in a clear way, and therefore both the PSP and the PLT know them. Furthermore, the reservation request also includes the user access credential Λ issued by the PSP. This credential is blinded, and therefore, the PSP nor PLT can learn it in this phase. Additionally, the access credential Λ is randomized with a session credential key sk_Cred. This key is generated by the user for each new reservation phase, and therefore, it differs for all user’s parking permits. Second, after the payment for the parking is done (see, 2.3. Perform payment), the PLT generates parking permit ID (see, 2.5. Generate parking permit) and computes a partially blind signature (Abe & Okamoto, 2000) on parking request data (both, clear and blind information) and sends it to the user (see, 2.6. Send parking permit). The user uses the partially blind signature from the PLT to reconstruct the parking permit CRED. The PSP and the PLT do not see the whole parking permit. They see only its public data, i.e., parking permit ID (PPID), parking location (PLTid), parking time (time_duration) and information about parking time extension (EPT).

3. Park vehicle phase: The user accesses the parking lot in this phase as illustrated in Fig. 4. To get access, the user must authenticate to the PLT first (see, 3.1. Authenticate and 3.2. Confirm). During the parking vehicle phase, the user communicates directly with the PLT, for example, via a Bluetooth communication interface. First, the user sends the parking permit to the PLT (see, 3.3. Send parking permit). The PLT checks the parking permit data and verifies the signature on the permit using PLT’s public key pk_PLT (see, 3.4. Verify signature). If the parking permit is valid, the users must prove that the parking permit belongs to them; (see, 3.5. Check user authentication proof), i.e., the permit includes the access credential Λ issued by the PSP and randomized by the user with the credential key sk_Cred. To do so, the user and the PLT run the Verify algorithm. The PLT checks the user’s authentication proof using PSP’s public key pk_PSP. If the proof is valid, the user is allowed to access the parking lot and the barrier is opened (see, 3.6. Allow vehicle to enter and Enter PLT and park vehicle). The parking permit includes user access credential Λ which can be used for linking the parking permit to the real identity of the user. However, this access credential is randomized with different credential keys in all issued user’s parking permits. Therefore, the PLT cannot link two different parking permits to the one user, and therefore, the user access parking lot anonymously and unlinkably. This prevents the possibility of profiling and tracking users across the system. The PLT is not able to get any information on how often users park their vehicles in the parking lot.

4. Extend parking time phase: The users can extend their parking time period using the Update algorithm as illustrated in Fig. 5. Users do not need to reveal any personal data to extend the parking time. The main assumption is that the PLT already has the user’s parking permit, i.e., the user parked the vehicle in the parking lot. First, the user sends the extension parking time request to the PSP (see, 4.1. Send the extension parking time request). This request includes PPID and PLTid information. Thanks to PLTid the PSP finds the relevant PLT (see, 4.2 Transfer the extension parking time request). Because of the PPID, the PLT finds the relevant parking permit (see, 4.3 Find relevant parking permit). If the extension parking time is possible (see, 4.4. Check if extension is possible), then the user and the PLT run the Verify algorithm in order to authenticate and authorize the user. If the user is authenticated, then the user and the PLT run the Issue algorithm with a new extended time period (see, 4.7. Issue parking permit and Fig. 3). The Issue algorithm is run after the payment for the extended parking time is made.

Privacy and security requirements

This section introduces general security and privacy requirements on the parking reservation system. In particular, we have the following system security requirements:

• Authentication: Parking permits from PSP should be granted only to valid non-revoked users who use them in the parking phase. The users should stay in anonymity but should prove that they hold valid parking permits (based on reservation) to PLT when the user arrives at a parking lot.

• Data confidentiality: All sensitive and personal data, e.g., Vehicle Plate Number (VPN) or vehicle IDs, should be secured. Data eavesdropping and exposure should be prevented by data encryption. The system should not reveal any sensitive personal data during issuing the parking permit and the park vehicle phase.

• Data authenticity and integrity: All exchanged data (e.g., parking permits, information about available slots, notifications) should be secured against their tampering by unauthorized parties.

Furthermore, we identify the following system privacy requirements:

• Data privacy: All stored and exchanged data should not be exposed to undesired parties and eavesdroppers, e.g., user’s vehicle ID, user parking history, and user profiles.

• Pseudonymity: A user should be pseudonymous and should be identifiable only in case of certain conditions by PSP. Users should not be identifiable while using the parking system by external and internal parties (PLTs) or other users.

• Unlinkability: PSP, PLTs, and other users should not be able to link together the parking actions of the same user (vehicle). The system should not scan VPNs.

• Conditional traceability: PSP should not be able to trace users’ credentials and their parking actions if the users are honest. PSP should be able to open a user’s identity from the parking permit only in case of serious fraud and by cooperation with PLT.

• Revocation: PSP should be able to conditionally open the parking permit credentials and identify the user. In a serious incident, PSP can remove a user from the system or remove the user’s anonymity. To do so, PSP should collaborate with PLT or, where appropriate, with other trusted third parties.

For data processing, it is necessary that the parking transaction records produced during the system use are stored and processed in a privacy-preserving manner at the PSP under the control of the PLT, thus leading to the following additional security and privacy requirements:

• Data minimisation: The transaction data items stored should be reduced only to the necessary data items for service usage analysis.

• Index and document privacy: The encrypted data used for statistics extraction should not reveal any sensitive information about the plaintext data and keywords (used for statistics purpose), to any unauthorized entities including the storing PSP.

• Query privacy: The type of statistics being performed should remain confidential, to the storing PSP.

• Access pattern privacy: No additional information should be revealed from the search results about the data involved.

• Query authorization: Statistics extraction should be limited to authorized entities and authorized keywords only.

Smart parking scenario and data protection requirements

The GDPR applies to any processing of personal data (EU, 2016; Art. 4). In its guidelines on connected vehicles, the European Data Protection Board (EDPB) states that: “Even if data collected by a connected car are not directly linked to a name, but to technical aspects and features of the vehicle, it will concern the driver or the passengers of the car” (EDPB, 2020; page 5). Under GDPR, personal data is therefore a broad notion (Purtova, 2018). Thus, in the scenario studied, there will be different ways of identifying data subjects, in particular through vehicle identification and payment service. Hence, use of such information fall under the material scope of GDPR.

In the scenario studied, additionally to the requirements of lawfulness (EU, 2016; Art. 5), of transparency (EU, 2016; Art. 12), of data accuracy (EU, 2016; Art. 5.1, d) and the data storage limitation (EU, 2016; Art. 5.1, e) (Knockaert et al., 2021; Art. 29 Working Party, Opinion 8/2014 on the Recent Developments on the Internet of Things, 16.09.2017, WP 223), a fundamental question is the appropriateness of identifying the service user. Indeed, the EU places at the heart of personal data protection the principle of protection by default and by design (EU, 2016; Art. 25, EDPD, 2019). To be compliant, one prior question is the need for user identification (EU, 2016; Art. 5.1, c). This implies determining, at each stage of the development of the service and according to the activities of the PSP and PLT, whether it is necessary to identify the person. Even if an identification is possible by the PSP with personal information such as mobile phone number, bank card and the credential, the minimisation principle is facilitated by the use of a third party, such as IDentity Provider (IDP), to avoid the collection of unnecessary personal data by the PSP. Additionally, each entity (IDP, PSP, and PLT) has no access to the same personal data.

Secondly, if identification is necessary, each entity responsible for the processing must favour the use of pseudonymisation (EU, 2016) (Art. 4.5) techniques. Indeed, the user is identified only in some situations by the PSP and the pseudonymisation is favoured for the PLT. The same credential than the one created by the PSP is pseudonymised for the PLT because these privacy-enhancing technique is sufficient to fulfil its purpose. The pseudonymisation is reinforced by unlikability parameters (PSP, PLTs or other users should not be able to link together parking actions of the same user if the parking permit is not recorded for a long period of time by the PLT (principle of storage limitation contained in Art. 5 EU, 2016). Finally, it is important to stress that the principle of minimisation is not only about the need or not to identify the data subject, but also about the need to determine an access policy to the personal data processed. Article 25.2 of the GDPR specifies that the control of accessibility to personal data is an integral part of the default data protection principle and states that: “In particular, such measures shall ensure that by default personal data are not made accessible without the individual’s intervention to an indefinite number of natural persons”. In this respect, the parking space reservation service and the payment service should be able to log who accessed to the data subject’s data and the possibility to determine whether they have consulted or modified the information are two security measures that should be implemented (Dumortier, 2018).⁴

The EDPB states that: “the plurality of functionalities, services and interfaces (e.g., web, USB, RFID, Wi-Fi) offered by connected vehicles increases the attack surface and thus the number of potential vulnerabilities through which personal data could be compromised (⋯) In addition, personal data stored on vehicles and/or at external locations (e.g., in cloud computing infrastructures) may not be adequately secured against unauthorized access” (EDPB, 2020), pages 11–12.⁵ According to article 32 of the GDPR, data controllers and data processors have to implement appropriate technical and organizational measures to ensure security of personal data, considering the state of the art, the costs of implementation, the type of personal data, and the potential risks. Several security measures are planned, notably for the communication between users and the PSP and the communication between the PSP and the PLT (see also Section ‘Scenario Phases’ concerning the architecture and the protocols used and Section ‘Privacy-Preserving Parking Solution’ regarding the cryptographic design). In particular, the cryptography and the pseudonymization technologies are cited by the GDPR as security measures making identification of data subjects more complex.

Additional privacy and security requirements

Bilinear pairing

Let 𝔾₁, 𝔾₂, and 𝔾_T be cyclic groups of the same prime order n, p ∈ 𝔾₁ , q ∈ 𝔾₂, and $\mathcal{O}$ is the point at infinity. 𝔾₁ and 𝔾₂ are additive groups and 𝔾_T is a multiplicative group. By definition (q, 𝔾₁, 𝔾₂, 𝔾_T, e, g₁, g₂) is a bilinear group if it satisfies all below properties:

• Bilinearity: ∀x, y ∈ ℤ_n, p ∈ 𝔾₁, q ∈ 𝔾₂:e(p^x, q^y) = e(p, q)^xy.

• Non-degeneracy: ∀p ≠ 𝒪∃q ∈ 𝔾₂:e(p, q) ≠ 1 ∈ 𝔾_T and ∀q ≠ 𝒪∃p ∈ 𝔾₁:e(p, q) ≠ 1 ∈ 𝔾_T.

• Computability: There exists an efficient algorithm $\mathcal{G}\left(1^{\kappa }\right)$ to compute e(p, q).

In this work, we consider the case 𝔾₁ ≠ 𝔾₂ that is when e is an asymmetric bilinear map and the Decisional Diffie–Hellman (DDH) assumption holds.

Weak Boneh-Boyen signature

The Weak Boneh-Boyen (wBB) signature scheme is a pairing-based short signature scheme. The scheme is provably secure and it is proven to be existentially unforgeable against a weak (non-adaptive) chosen message attack (Boneh & Boyen, 2008). The scheme can be easily combined with the zero-knowledge proofs as shown in Camenisch, Drijvers & Hajny (2016). This makes it possible to prove the authorship of signed messages in an unlinkable and anonymous manner. Below is a brief illustration of the wBB signature (Boneh & Boyen, 2008):

• (pk, sk, syspar)←KeyGen $\leftarrow \left(1^{\mathcal{\kappa }}\right)$: On the input of the security parameter $\mathcal{\kappa }$, the algorithm generates system parameters syspar = (q, 𝔾₁, 𝔾₂, 𝔾_T, e, g₁ ∈ 𝔾₁, g₂ ∈ 𝔾₂), computes $pk=g_2^{sk}$, where sk∈_Rℤ_q, and outputs sk as the private key and (pk, syspar) as the public key.

• (σ)←Sign ←(m, syspar, sk): On the input of the message m ∈ ℤ_q, the system parameters syspar and the secret key sk, the algorithm outputs the signature of the message $\sigma =g_1^{\frac{1}{sk+m}}$.

• (1/0)←Verify ←(σ, m, pk, syspar): On the input of the system parameters syspar, the public key pk, a signature σ and a message m, the algorithm returns 1 if and only if e(σ, pk)⋅e(σ^m, g₂) = e(g₁, g₂) holds, i.e., the signature is valid, or 0, otherwise.

Short group signature HDMR18

The article (Hajny et al., 2018) presents a short and fast group signature scheme (HDMR18) based on the wBB proposal. The signature allows a signer to generate an anonymous signature σ(sk_i, m) on a message m, where sk_i is the signer’s private key. The protocol works as follows:

• (pk, sk_m, spar)←Setup $\leftarrow \left(1^{\mathcal{\kappa }}\right)$: On the input of the security parameter $\mathcal{\kappa }$, the algorithm generates the system parameters spar = (q, 𝔾₁, 𝔾₂, 𝔾_T, e, g₁ ∈ 𝔾₁, g₂ ∈ 𝔾₂) satisfying $\left|q\right|=\mathcal{\kappa }$. It also generates the manager’s private key sk_m∈_Rℤ_q and computes the public key $pk=g_2^{s{k}_m}$. It outputs the (pk, spar) as a public output and the sk_m as the manager’s private output.

• (sk_i, RD)←KeyGen ←(id_i, sk_m): On the input of manager’s private key sk_m and signer’s private identifier id_i, the protocol outputs the wBB signature $s{k}_i=g_1^{\frac{1}{s{k}_m+i{d}_i}}$ to the signer and updates the manager’s revocation database RD by storing id_i.

• σ(sk_i, m)←Sign ←(m, id_i, sk_i): On the input the signer’s private identifier id_i, signer’s private key sk_i, and the message m, the algorithm outputs the signature $\sigma \left(s{k}_i,m\right)=\left(g_1^{\prime },s{k}_i^{\prime },\overline{s{k}_i},\pi \right)$, where:

  • $g_1^{\prime }=g_1^r$: The generator raised to a randomly chosen randomizer r∈_Rℤ_q.

  • $s{k}_i^{\prime }=s{k}_i^r$: The signers’ private key raised to the randomizer.

  • $\overline{s{k}_i}={s{k}_i^{\prime }}^{-i{d}_i}$: The randomized private key raised to the signer identifier.

  • $\pi =SK\left\{\left(i{d}_i,r\right):\overline{s{k}_i}={s{k}_i^{\prime }}^{-i{d}_i}\wedge g_1^{\prime }=g_1^r\right\}\left(m\right)$: The proof of knowledge of r and id_i signing the message m.

• (0/1)←Verify ←(σ(sk_i, m), m, pk, BL): On the input of the message m, its signature σ(sk_i, m), a BlackList (BL), and the public key pk, the algorithm checks the proof of knowledge signature π and checks that the signature is valid with respect to the manager’s public key using the equation $\mathbf{e}\left(\overline{s{k}_i}\cdot g_1^{\prime },g_2\right)\stackrel{?}{=}\mathbf{e}\left(s{k}_i^{\prime },pk\right)$. The collector also performs the revocation check $s{k}_i^{\prime }\stackrel{?}{=}{\overline{s{k}_i}}^{i{d}_i}$ for all id_i values stored on the BL. If the revocation check equation holds for any value on the blacklist, the signature is rejected. Otherwise, the signature is accepted if all other checks pass.

Partially blind WI-Schnorr signature

A form of digital signature known as a blind signature conceals the message’s content from the signer. The resulting blind signature can then be publicly verified against the original (unblinded) message and used as a regular digital signature. This technology is mostly utilized in privacy-enhancing protocols where the message’s owner and signer are separate entities. In a partially blind signature, the signer may include common public information in the signature (for example, an expiration date). Therefore, the verifier needs the message, the common information, and the signature in order to verify the signature’s authenticity. The WI-Schnorr signature, which is a partially blind signature based on the Schnorr protocol and maintains the Witnesses Indistinguishability (WI), was proposed by Abe & Okamoto (2000). The WI-Schnorr signature is depicted in Fig. 6. It is deemed that both the signer and the user have already agreed upon the public value “info”.

Searchable encryption: outsourced private information retrieval

A privacy enhancing technology that can facilitate privacy-preserving data processing is Searchable Encryption (SE), which enables storing a dataset in an encrypted form, while remaining searchable. This process relieves the service provider of the responsibility to maintain and protect the data from data breaches, as well as unauthorized use within the system.

Structured Encryption (STE) is a searchable encryption variation that provides balance between efficiency, functionality and security (Gan et al., 2019; Kamara, 2015). Non-interactive STE schemes produce encrypted structures that can be queried using a single message containing a token, whereas in interactive schemes, queries are performed through an interactive two-party protocol. Searchable Symmetric Encryption (SSE) schemes are a special case of STE that specializes for keyword search. In this setting, a data owner creates a data structure with efficient search support, such as an inverted index. Each document in the dataset is then encrypted, forming the Encrypted DataBase (EDB) and outsourced to an external search service. This enables performing queries on the dataset without revealing information about the dataset or the queries to the search service. The encrypted dataset consists of a list of document identifier and keyword-set pairs. Queries are performed using a search token, generated by the data owner, that allows the server to search through the index. A search query returns the document identifiers that satisfy the query expression. In general, an SSE scheme includes the following main algorithms (Gan et al., 2019; Kamara & Moataz, 2017):

• (sk, Δ)←Setup ←(1^κ, DB): Using a security parameter κ as input and a database DB, consisting of a list of document identifiers and keywords, it outputs the secret key sk and an encrypted data structure Δ that will be outsourced to the data server. This algorithm varies depending on the specific SSE scheme and the data structures they use.

• (Γ)←Token generation ←(sk, q): Using the secret key sk and the query q, it returns a query token Γ, to be used during search.

• (Φ)←Search ←(sk, q, Γ, Δ): Using the secret key sk, the query q, and a search token Γ submitted by the user, the data server performs the search operations on encrypted data structure Δ, returning the matching documents. The algorithm outputs a set of encrypted documents Φ.

Depending on the SSE scheme, query expressiveness varies, supporting single-keyword, conjunctive, disjunctive or boolean queries.

Detailed description of our algorithms

In this section, we instantiate the algorithms and protocols of the privacy-preserving parking system presented in the previous section using the wBB signature (Boneh & Boyen, 2008) and its efficient proof of knowledge (Camenisch, Drijvers & Hajny, 2016). Note that the proposal does not provide non-repudiation property of user proofs, and therefore, the PSP has to be trusted. The proposed solution uses randomly generated parking permit secret keys sk_Cred in each Issue parking permit phase. The users’ private keys sk_U are static, and they are given to users during the Registration phase. On a high level, we let the users obtain a wBB signature Λ on their; private secret keys sk_U from the PSP. This signature represents the user’s access credential. The revocation and identification of the malicious user are possible due to using this signature. Then, the user and the PLT together create the parking permit, which includes the randomized signature $\hat{\Lambda }$. To do so, they use a partially blind signature scheme (Abe & Okamoto, 2000). The PSP and the PLT learn nothing about the value $\hat{\Lambda }$ during the Parking permit issuing phase. In fact, the value $\hat{\Lambda }$ is blinded. Finally, the user proves the knowledge of signature $\hat{\Lambda }$ anonymously and efficiently using the Schnorr-like zero-knowledge protocol for proving the knowledge of a discrete logarithm (Camenisch & Stadler, 1997) during the Parking vehicle phase. For the conversion from the proof of knowledge to the signature, we use the Fiat-Shamir heuristics (Fiat & Shamir, 1986). We present the concrete algorithm and protocol instantiations below. To make our protocols easier to follow, we provide several illustrative figures (namely Figs. 7–10) describing our protocols algorithmically and which can be read from top to bottom.

Optional extension of the system supporting the non-repudiation feature

The proposal of the parking system presented in the ‘Description of Our Algorithms’ section does not provide non-repudiation features. In fact, the PSP knows all secret keys sk_U of all system users. Thanks to this knowledge, the PSP can revoke users by running the Revoke algorithm. On the other hand, the malicious PSP can forge valid parking permits for all system users, and therefore, falsely accused of committing a crime on anyone in the system. Due to this fact, the PSP must be trusted and honest. However, if the system implementer requires non-repudiation features, we have proposed a solution as well. The solution is based on using a secure two-party computation of wBB signature within the Register algorithm. We refer to Belenkiy et al. (2009) and Ricci et al. (2021) for more details. Our extension impacts only Registration and Revoke algorithms presented in Section ‘Description of Our Algorithms’. The other algorithms remain unchanged. The extended Registration algorithm is depicted in Fig. 10.

The algorithm takes on the input system parameters spar = (q, 𝔾₁, 𝔾₂, 𝔾_T, e, g₁, g₂) and parameters (g, h, n, g, h, n) (Belenkiy et al., 2009), where n is RSA-modulus of size at least 2^3κq², κ is a security parameter, h = n + 1, g is an element of the order ϕ(n)modn², n is RSA modulus such that neither the user nor the PSP knows its factors (e.g., n can be provided by a TTP), h and g are two elements in ${\mathbb{Z}}_{\text{n}}^{\ast }$ such that log_gh is unknown and g ∈ 〈h〉. The algorithm is run by the user and the PSP as in main scheme and allows computing user’s access credential $\Lambda =g_1^{1/\left(s{k}_{PSP}+s{k}_U\right)}$ without that the PSP reveals its private key sk_PSP and the user its secret key sk_U. The algorithm is based on homomorphism of Paillier cryptosystem (Paillier, 1999). Fist, the PSP homomorphicly encrypts its secret key sk_PSP by computing e₁ = h^n/2+sk_PSPg^rmodn² and computes commitment textgothc₁ = g^sk_mh^r′modn. Then, the PSP and the user run the PK protocol: ${\displaystyle {\pi }_1=PK\left\{\left(s{k}_{PSP},r,r^{\prime }\right):e_1/{\mathbf{h}}^{\mathbf{n}/2}={\mathbf{h}}^{s{k}_{PSP}}{\mathbf{g}}^{r}mod{\mathbf{n}}^2\wedge {\text{c}}_1={\text{g}}^{s{k}_{PSP}}{\text{h}}^{r^{\prime }}mod\text{n}\right\}}$

If the proof π₁ is accepted by the user, the user homomorphicly encrypts its secret key sk_U by computing $e_2={\left(e_1/{\mathbf{h}}^{\mathbf{n}/2}\right)}^{r_1}{\mathbf{h}}^{\left(\mathbf{n}/2+s{k}_U\right)r_1+r_{2}q}{\mathbf{g}}^{\bar{r}}mod{\mathbf{n}}^2$ and computes commitment ${\text{c}}_2={\text{g}}^{i{d}_i}{\text{h}}^{\bar{r}}mod\text{n}$ and its public key $p{k}_U=g_2^{s{k}_U}$. Then, the PSP and the user run the PK protocol: ${\displaystyle {\pi }_2=PK\left\{\left(s{k}_U,r_1,r_2,s{k}_U^{\prime },u,\bar{r}\right):e_2/{\mathbf{h}}^{\mathbf{n}/2}={\left(e_1/{\mathbf{h}}^{\mathbf{n}/2}\right)}^{r_1}{\mathbf{h}}^{s{k}_U^{\prime }}{\left({\mathbf{h}}^q\right)}^{r_2}{\mathbf{g}}^{\bar{r}}mod{\mathbf{n}}^2\wedge {\text{c}}_2={\text{g}}^{s{k}_U}{\text{h}}^{\bar{r}}mod\text{n}\wedge 1={\text{c}}_2^{r_1}{\left(1/\text{g}\right)}^{s{k}_U^{\prime }}{\text{h}}^{u}mod\text{n}\wedge p{k}_U=g_2^{s{k}_U}\right\}.}$

If the proof π₂ is accepted by the PSP, the PSP decrypts (i.e., Paillier decryption) x = Dec(e₂) − n/2, computes ${\Lambda }^{\ast }=g_1^{1/x}$ and sends it to the user. The user computes Λ = (Λ^∗)^r₁ and verifies that it is a correct signature on sk_U, i.e., $\Lambda =g_1^{\frac{1}{s{k}_U+s{k}_{PSP}}}$ holds.

The PSP can open the parking permit CRED and track the malicious users by running the modified Revoke algorithm. With the PSP’s revocation database RD and the parking permit CRED, the PSP checks if the equation $\mathbf{e}\left(\hat{\Lambda },p{k}_U^{-1}\right)\stackrel{?}{=}\mathbf{e}\left(\bar{\Lambda },g_2\right)$ holds for any of pk_U in its RD. If there exists an pk_U for which this equation holds, pk_U is linked with the user’s ID, which is then sent to the corresponding identity provider to identify the user.

Security and privacy analysis

The proposed system is built on provable secure cryptographic primitives such as wBB signature (Boneh & Boyen, 2008), group signature (Hajny et al., 2018), partially blind WI-Schnorr signature (Abe & Okamoto, 2000) and secure two-party computation of wBB signature (Belenkiy et al., 2009). We refer to these articles for more details on their security analyses. In the security and privacy analysis of our proposal, we adopt the attacker model for the privacy-preserving parking system defined in Dzurenda et al. (2021) and apply it to our security and privacy requirements defined in Section ‘Parking Scenario Description’. The attacker model considers both internal and external adversaries. In the case of internal attackers, the PSP and the PLT are considered honest-but-curious, while users can act maliciously. Entities omitting the proposed protocols to commit fraud are considered external attackers. Considering this adversary model, we get the security and privacy properties of our system and how they are fulfilled. Note that, we define four lemmas that are in line with our requirements from Section ‘Parking Scenario Description’. See Section ‘Parking Scenario Description’ for more details. Namely, Lemma 5.1 is in line with Conditional traceability and Revocation requirements, Lemma 5.2 is in line with Data confidentiality, Data privacy, Pseudonymity, and Unlinkability requirements, Lemma 5.3 is in line with Authentication requirement, and Lemma 5.4 is in line with Data authenticity integrity requirements.

Experimental results

In this section, we provide our experimental results. In particular, we show the efficiency of our proposal on Android devices. We use the Android phones: Honor 8X (chip: Kirin 810, OS: Android 10, RAM: 4 GB) and OnePlus Nord 5G (chip: Snapdragon 765G, OS: Android 11, RAM: 8 GB). In order to perform cryptographic operations, we use the MCL (Shigeo, 2018) C++ library (using C++17 version of the ISO/IEC 14882 standard); and Android Native Development Kit (NDK). The Android NDK allows us to execute a program in C/C++ on Android devices instead of using Java libraries, and therefore, to achieve better performance results. The source code of the Android application is available online on the GitLab repository (https://gitlab.com/brno-axe/tacr-crypto/android-mcl-test). Our benchmark test on both phones for different arithmetic operations and fields is presented in Table 2. We measure the time complexity of each MCL operation 10 times and then compute the median from these data. From the table, we can see that the time complexity of operations in 𝔽_r is negligible. They take approximately 30 µs for the BN254 elliptic curve on OnePlus Nord 5G. A similar situation is in the case of operations in 𝔾₁ and 𝔾₂. The most expensive operations are scalar multiplication mul1, mul2, modular exponentiation powT, and bilinear pairings pairT. These operations have a significant impact on the time complexity of the whole protocol.

To show the complexity of our system, we sum up the algebraic operations used in the cryptographic algorithm (i.e., Register, Issue, Verify, Update and Revoke) for each involved system entity and compute the execution time. To do so, we used data from Table 2. In particular, we consider using the OnePlus Nord 5G Android device and the BN254 elliptic curve. Considering our results in the Table 3, the cryptographic core time complexity is negligible, since it takes ca. 6 ms for Issue, ca. 9 ms for Verify and ca. 14 ms for Update algorithm.

The complexity of the Revoke algorithm is linearly dependent on the number of users in the system. The time complexity of Revoke algorithm for both main scheme (see ‘Detailed Description of Our Algorithms’) and extended scheme (see ‘Optional Extension of the system supporting the non-repudiation feature’) based on number of system user is depicted in Fig. 11. The main algorithm requires performance of N operations of mul1, while the extended algorithm requires the performance of N operations of pairT), where N is a number of system users. If we consider OnePlus Nord 5G Android device and 1 million system users, the Revoke algorithm will need ca. 9 min; (i.e., main algorithm) and ca. 47 min; (i.e., extended algorithm) to identify a malicious user. By using more powerful servers and palatalization techniques, the revocation time can be reduced significantly.

Our MC-SSE system model and overview

The following entities are interacting in the data processing system for the parking scenario, as illustrated in Fig. 12:

• The data owner (D): Creates an encrypted dataset and outsources it. In our scenario the PLT acts as the data owner.

• The storage and query server (S): Handles the encrypted dataset storage and performs queries on it.

• Search clients (C): They are allowed to search on the encrypted dataset. The PSP, other PLTs in the parking system, or any other interested stakeholder can act as a search client.

To achieve the multi-client extension of BIEX, the data owner provides Search clients an authorization token that enables them to create search tokens and submit queries to the Server limited by the keywords contained in the authorization token. With this extension the properties of the BIEX scheme are preserved, i.e., boolean query support with efficient search, while enabling multi-client functionality.

Refining the security and privacy threat model

As considered in classical SSE schemes, the server S is honest-but-curious, thus fulfilling the search tasks over the database correctly, but attempting to collect as much data as possible. The clients C are malicious and the data owner D is honest. We only consider internal attackers as all the channels between any interacting entities - D-S, D-C and S-C - are authenticated.

In the light of the system model of section ‘Our MC-SSE System Model and Overview’, additionally to the security and privacy requirements identified in the ‘Privacy and Security Requirements’ section—data minimisation, index and document privacy, query privacy, access pattern privacy, the query authorization requirement are revisited for the multi-client SSE scheme as follows:

• Query authorization: Only authorized clients on authorized keywords are able to extract statistics from the server.

• Privilege escalation prevention, as a sublease of the query authorization issue: Clients must not be able to collude for generating a search token with a superset of combined keywords.

Our MC-SSE algorithms

The Multi-Client SSE (MC-SSE) scheme consists of the following algorithms:

• (sk,EDX,EMM)← Setup ←(κ, DB): Taking as input a security parameter κ and an index database DB, it outputs the secret key sk, an encrypted dictionary EDX, and an encrypted multi-map EMM. The algorithm is run by the data owner (D).

• (Γ)←Authorization token generation ←(sk, W_auth): Using as input the secret key sk and a vector of keywords W_auth = (w₁, …, w_q), for each keyword w_i in the vector, it creates a sub-token Γ_i = (gtk_i, dtk_i, ltk_j) containing a global token gtk_i, a dictionary token dtk_i and for all keywords w_j, with 1 ≤ j ≤ q and j ≠ i, a local token ltk_j. The algorithm is run by the data owner (D) and outputs authorization token Γ = (Γ₁, …, Γ_q).

• (γ)←Search token generation ←(Γ, Δ): Using as input an authorization token Γ and a boolean query Δ, where Δ is a query written in conjunctive normal form (CNF) as Δ₁∧⋯∧Δ_l, and where each Δ_i = w_i,1∨⋯∨w_i,q is a disjunction, for the first disjunction Δ₁ it calculates the disjunction IEX sub-token γ₁ as follows: For every following disjunction Δ_i, 2 ≤ i ≤ l it computes the sub-token γ_i containing the local tokens between every keyword in Δ₁ and every keyword of Δ_i, as follows: The algorithm is run by the search client (C) and the final output is a search token γ = (γ₁, …, γ_q′).

  • for each keyword w_1,j in Δ₁ except the last, it creates the sub-token ${\gamma }_{1,j}=\left(\overline{gt{k}_{1,j}},\overline{dt{k}_{1,j}},\overline{lt{k}_{k,j}}\right)$ containing the global token $\overline{gt{k}_{1,j}}$, the dictionary token $\overline{dt{k}_{1,j}}$ and for all keywords w_1,k, with j + 1 ≤ k ≤ q′, the local token $\overline{lt{k}_{k,j}}$. Finally, for the last keyword w_1,q′ only the global token $\overline{gt{k}_{1,q^{\prime }}}$ is kept and the output is the search token ${\gamma }_1=\left({\gamma }_{1,1}\cdots {\gamma }_{1,q^{\prime }-1},\overline{gt{k}_{1,q^{\prime }}}\right)$.

  • for each keyword w_1,j in Δ₁ it calculates the vector of local tokens $\overline{lt{k}_{j,i}}=\left(\overline{lt{k}_{j,i,k}}\right),1\le k\le q^{\prime }$ between the keyword w_1,j in the first disjunction and every keyword k in the ith disjunction. Then the output is ${\gamma }_i=\left(\overline{lt{k}_{1,i}}\cdots \overline{lt{k}_{q^{\prime },i}}\right)$.

• (T) Search ← (EDB,γ ): Using as input EDB =(EDX, EMM) and a search token γ = (γ₁, …, γ_q′), for the first search sub-token ${\gamma }_1=\left({\gamma }_{1,1}\cdots {\gamma }_{1,q^{\prime }-1},\overline{gt{k}_{1,q^{\prime }}}\right)$, the server performs the IEX search as follows: For every following search sub-token ${\gamma }_i=\left(\overline{lt{k}_{1,i}}\cdots \overline{lt{k}_{q^{\prime },i}}\right),i\ge 2$, the server: At the end, the server outputs the remaining set of identifiers in T₁, which is the resulting set of document identifiers for the query Δ. The algorithm is run between the search client (C) and the storage and query server (S).

  • For every element ${\gamma }_{1,i}=\left(\overline{gt{k}_{1,i}},\overline{dt{k}_{1,i}},\overline{lt{k}_{k,i}}\right),1\le i\le q^{\prime }-1$:

    • First it uses $\overline{gt{k}_{1,i}}$ to query the global multi-map EMM, to recover the set T_1,i of document identifiers containing w_i.

    • Then it uses $\overline{dt{k}_{1,i}}$ to query the encrypted dictionary EDX to recover the local multi-maps for w_i.

    • Finally, it uses the local tokens $\overline{lt{k}_{k,i}}$, with i + 1 ≤ k ≤ q′ to query the local multi-maps, to recover the set of document identifiers T′ that contain both w_i and w_k and removes them from T_1,i.

  • For the last element in γ₁, $\overline{gt{k}_{1,q^{\prime }}}$, it recovers the document identifiers T_1,q′ containing w_q′.

  • Finally, the server calculates the set of document identifiers T₁, containing the document identifiers T_1,i through T_1,q′.

  • Uses $\overline{dt{k}_{1,i}}$ from γ₁ to query the encrypted dictionary EDX to recover the local multi-maps for w_i.

  • Then, it uses the local tokens $\overline{lt{k}_{k,i}}$, with 1 ≤ k ≤ q′ to query the local multi-maps, to recover the set of document identifiers T_k,i that contain both w_i and w_k.

  • Then it calculates the union of all the common document identifiers T_i = ⋃_kT_k,i

  • and finally replaces T₁ with the intersection of T_i and T₁.

Note that the Setup and Search algorithms of the MC-SSE scheme are the same as the Setup and Search algorithms of the original BIEX scheme.

Security and privacy analysis

Our MC-SSE scheme is built over the BIEX scheme for which several SSE requirements have been proven. Based on the MC-SSE threat model presented in ‘Refining the Security and Privacy Threat Model’ and security and privacy requirements presented in Section ‘Privacy and Security Requirements’, a security and privacy analysis is conducted below for each of the expected requirements:

Experimental results

The MC-SSE evaluation consisted of experiments with up to 1 million documents, containing synthetic parking transactions, resulting in 21 million document-keyword pairs. Experiments were conducted on both the original BIEX scheme and the MC-SSE scheme for the same dataset. The source code of the Clusion BIEX library is available online on the GitHub repository (https://github.com/encryptedsystems/Clusion) and the source code for the multi-client extension of the Clusion BIEX library is available on the on the GitHub repository (https://github.com/atasidou/MC-Clusion). A docker container with the multi-client library extension bundled with a web application for testing its functionality is also available online on the Docker Hub repository (https://hub.docker.com/r/atasidou/multi-client_clusion). Experiments were executed on the Grid’5000 testbed (https://www.grid5000.fr/) with Intel Xeon Gold 6130 (Skylake, 2.10 GHz, 4 CPUs/node, 16 cores/CPU) processors and 60 GB of RAM, running Debian 11 (64-bit) OS. The experimental results confirm the correct functionality of the multi-client extension of the BIEX SSE scheme library. The performance evaluation of the MC-SSE library implementation shows that the properties of the original BIEX SSE scheme algorithm are retained, offering practical and efficient boolean search functionality.

In particular, as illustrated in Fig. 13, the efficiency of the search functionality for MC-SSE is consistent with the original BIEX performance, taking approximately 3–30 ms, to perform a boolean search over 1 million documents (21 million document-id pairs). Note that the query expression includes two disjunctions (sub-queries) with 2 keywords each, of the form ((w∨x)∧(y∨z)), with the search time depending on the selectivity of the first disjunction ((w∨x)) of the query, i.e., the number of documents returned by the first sub-query. The slightly smaller times in the MC-SSE search duration presented, mainly in higher values of the search times, is due to slight improvements in the Java code for the implementation of the search functions in the Clusion library.

In the multi-client version of the scheme, the main difference is the creation of the authorization token Γ, which includes a superset of all the sub-tokens for the included keywords, hence being larger in size compared to the equivalent BIEX search token. The experimental evaluation for the overhead introduced by the authorization token Γ consisted of creating authorization tokens and BIEX tokens for the same keywords and measuring the creation time and serialized size of the resulting tokens. For both types of tokens, the creation of tokens for keyword set sizes from N ∈ [1, …, 100] was evaluated, taking each time the N most frequent keywords in the dataset.

As illustrated in Fig. 14, the creation of the authorization token Γ for the multi-client extension of BIEX, shows that the performance of the creation of the authorization token Γ displays the same general trend as the BIEX token creation, being exponential with the number of keywords in the token. Despite the creation time of the authorization token Γ being higher than the one of the BIEX token, it is just a constant factor higher and remains reasonable in absolute terms. The increased creation time is expected, as the authorization token Γ includes approximately double the elements compared to the corresponding BIEX token for the same keyword set, as illustrated in Fig. 15.