Security Reductions for White-Box Key-Storage in Mobile Payments

. The goal of white-box cryptography is to provide security even when the cryptographic implementation is executed in adversarially controlled environments. White-box implementations nowadays appear in commercial products such as mobile payment applications, e.g., those certiﬁed by Mastercard. Interestingly, there, white-box cryptography is championed as a tool for secure storage of payment tokens, and importantly, the white-boxed storage functionality is bound to a hardware functionality to prevent code-lifting attacks. In this paper, we show that the approach of using hardware binding and obfuscation for secure storage is conceptually sound. Following security speciﬁcations by Mastercard, we ﬁrst deﬁne security for a white-box key derivation functions (WKDF) that is bound to a hardware functionality. WKDFs with hardware-binding model a secure storage functionality, as the WKDFs in turn can be used to derive encryption keys for secure storage. We then provide a proof-of-concept construction of WKDFs based on pseudorandom functions (PRF) and obfuscation. To show that our use of cryptographic primitives is sound, we perform a cryptographic analysis and reduce the security of our WKDF to the cryptographic assumptions of indistinguishability obfuscation and PRF-security. The hardware-functionality that our WKDF is bound to is a PRF-like functionality. Obfuscation helps us to hide the secret key used for the veriﬁ-cation, essentially emulating a signature functionality as is provided by the Android key store.


Introduction
Near-field communication (NFC) protocols have opened up new possibilities for mobile payment applications, such as those offered by Mastercard, Visa, or Google wallet [Sma14].Traditionally, the NFC traffic was processed by a secure hardware component in mobile devices, that performed cryptographic operations.In 2015, Android 4.4 introduced Host Card Emulation (HCE), which allows the application processor of a mobile device to use the NFC communication, too.In this case, the cryptographic functions of mobile applications are implemented software-only, increasing flexibility and device coverage of the applications since no secure hardware element is required.However, implementing cryptographic functions in software leads to new attack vectors.
White-box cryptography.One of the core cryptographic protection technologies for HCE (as listed by the Smart Card Alliance Mobile & NFC Council [Sma14]) is the use of white-box cryptography.Cryptography in the white-box attack model was introduced by Chow, Eisen, Johnson, and van Oorschot in 2002 (CEJO [CEJvO03,CEJv03]).In the white-box attack scenario, an adversary has access to the program code and the complete execution environment of a cryptographic implementation, and the goal of white-box cryptography is to remain secure despite such strong attack capabilities.Unlike in the Digital Rights Management scenario considered by CEJO where the user is considered as an adversary, in an HCE context, the goal of white-box cryptography is protect an honest user against attacks performed on their device, e.g., by malware that can observe program code and executions.
Commercial payment applications.Payment applications need to store secret information such as transaction tokens that are decrypted when a transaction is performed.In the absence of a secure element, the tokens are stored in insecure memory and likewise, the decryption operations are performed by an insecure CPU.Thus, to protect against adversaries that use their access to the storage/CPU to extract secret information and perform payment transactions on their own, over the past years, white-box cryptography has been broadly adopted by those offering commercial payment applications.The Mastercard security guidelines for payment applications, for instance, make the use of whitebox cryptography mandatory for implementing storage protection in order to achieve an advanced security level (see Local Database Encryption, Chapter 5 in [Mas17]).
For a successful payment, the user's device needs to be close to an NFC reader.An attacker on a user's device can thus only alter a payment a user aims to make, but cannot make payments independently at readers of their choice, 5 unless the attacker gains independence from the user's device.The attacker could gain independence by (a) extracting the key, or (b) performing a code-lifting attack [Wys12].Thus, white-box cryptography in commercial payment applications needs to achieve hardware-binding (also see [CdRP14,SdHM15,BBIJ17] for discussions of usefulness).As a consequence, commercial applications implement white-box cryptography with a hardware anchor, essentially reaching a middle-ground between software-only and hardware-only security for cryptographic implementations.
Hardware-binding on Android.The Mastercard guidelines (see Chapter 5 in [Mas17]) recommend, to the very least, to use a unique device fingerprint for device identification.For instance, Android allows to perform checks on identifiers such as the hardware serial number, the ESN (electronic serial number) or IMEI (international mobile equipment identity) of the device via its Build and TelephonyManager classes [And18a,And18c].This technique helps to mitigate code-lifting attacks as long as the value remains secret and/or interception of this value between hardware and software can actually be prevented.For an advanced security level, however, the guidelines suggest the use of the functionalities of the Android Key Store.The Android Key Store, e.g., implements RSA signatures, and relies on whatever secure hardware features the Android device provides.Signatures are a more useful binding functionality than single identifier values, since for each new input, they provide a different output.
Conceptual validation.In this paper, we show that the wide-spread practical approach for building secure payment applications based on white-box cryptography is conceptually sound.We split our study into two parts: a hardware-bound white-box key derivation function (WKDF) which provides (1) hardware-binding and (2) secure storage; a secure payment application that performs (3) symmetric encryption of data on top of the WKDF.
Note that the Mastercard guidelines merely specify best practices but omit a design blueprint.Our goal is to explicate how exactly a sound design shall proceed, and what security properties the underlying primitives should obey.
Hardware-bound white-box key derivation function (WKDF).Our WKDF notion builds on top of a standard (black-box) key derivation function (KDF).We here consider a lightweight notion for the KDF that takes uniformly random keys and a second, non-random value as input, and returns pseudorandom keys of fixed length.We therefore use the terms KDF and pseudorandom function (PRF) interchangeably, abstracting away additional KDF features such as varying output lengths (c.f.Krawczyk [Kra10]).We introduce the IND-WKDF security notion for WKDFs that models the previously discussed white-box attack scenario.I.e., the adversary is given full access to the white-box implementation of the WKDF as well as limited access to the hardware.If the adversary uses its hardware access, the adversary is able to evaluate the WKDF, but if the adversary has no access to the relevant hardware values, e.g., carrying out a code-lifting attack, then the adversary learns nothing about the WKDF values, which is modeled by a real-or-random oracle for derived keys.
Here, an adversary shall not be able to compress a cryptographic program without losing part of its functionality.Incompressibility seems unrelated to achieving the goal of real-or-random key indistinguishability for derived keys, as we aim for the WKDF in our application.Additionally, DLPR define traceability which is a security notion intended to trace malicious users (typically in a DRM setting) if they illegally share their white-box program with others.Traceability is a helpful to mitigate code-lifting and re-distribution attacks in the case of malicious users, but not helpful to protect honest users from adversaries copying and misusing their software.Finally, DPLR also discuss one-wayness and security against key extraction, a baseline security property for white-box cryptography, which are both implied by our IND-WKDF notion for WKDF.Namely, if an adversary can extract the key, then the adversary can evaluate the KDF on all points itself and thereby distinguish derived keys from random keys.Similarly, an adversary can use an inversion algorithm to distinguish real derived keys from random values.Thus, a IND-WKDF-secure WKDF also resists key extraction and inversion attacks.
Secure payment application.We introduce a secure hardware-bound payment application scheme (WPAY).Its basic functionality is to encrypt and to authenticate valid payment requests to a server.We model validity by a predicate that acts as filter function.E.g., the filter could only allow for certain date ranges or limits the upper bound on the payment, while the server generically accepts payments of arbitrary amounts and ranges.
Our security notion IND-WPAY gives the adversary the white-box payment application WPAY.The adversary can query a hardware oracle that provides them with the necessary hardware values to generate a request using WPAY.This models that the adversary can observe (and interfere with) honest user evaluations.As soon as the adversary loses access to the hardware, confidentiality and integrity of the user requests should hold.IND-WPAY models both properties via an indistinguishability game.Note that in particular, IND-WPAY captures code-lifting attacks.Namely, the adversary has access to WPAY throughout the experiment, but only limited access to the hardware.IND-WPAY models that in the absence of the hardware, no valid requests can be generated, even given WPAY.
Constructions.To instantiate our approach for building a WKDF, we first need to specify a hardware functionality.One idea could be to rely on a signa-ture functionality as provided for example by the Android Key Store.I.e., WKDF would send a request to the hardware, the hardware signs it, and WKDF then verifies the signature with the public verification key.But we need to (1) hide the software-related key of our WKDF and (2) make it inseparable from the verification algorithm that checks hardware values, which is both achieved by applying indistinguishability obfuscation techniques.This, in turn, forces us to use puncturable primitives for the security reduction to work.One option could thus be to use the puncturable signature scheme by Bellare, Stepanovs and Waters [BSW16] which, notably, itself is based on indistinguishability obfuscation.To avoid this double form of obfuscation for the construction, one layer for the puncturable signature scheme and one for the hiding and binding of our KDF key, we instead use a faster symmetric-key primitive in form of a (puncturable) PRF (essentially as a message authentication code).This puncturable PRF is obfuscated once within the hardware-linked KDF construction to ensure the required security.
Hence, we build a WKDF and prove its IND-WKDF security, following techniques by Sahai and Waters [SW14].This construction assumes puncturable PRFs (which are equivalent to one-way functions) and indistinguishability obfuscation.Given and IND-WKDF-secure WKDF we then prove that another layer of indistinguishability obfuscation can be used to bind the WKDF to an arbitrary secure symmetric encryption scheme and a filter function to obtain an IND-WPAY-secure white-box payment application WPAY.
Discussion and limitations.Note that our constructions are conceptual validations and not practically efficient due to the tremendous inefficiency of indistinguishability obfuscation (see [AHKM14]).In practice, the obfuscation need to be implemented by a mix of efficient obfuscation techniques, combined with practical white-box techniques, e.g.[GPRW18].Thus, our work does not allow to immediately bypass the difficulty of building white-box implementations -as apparent in the past white-box competitions [ECR17,cyb19], where only three design candidates submitted towards the end of the second competition remained unbroken-in practice.However, our theoretical feasibility result allows us to conclude that secure white-box implementations based on strong cryptographic assumptions -indistinguishability obfuscation is not yet a mature cryptographic primitive-are indeed possible.Our results not only affirm that building secure white-box cryptography is possible, but they also explain how such a secure white-box implementation can be designed.
As efficiency of indistinguishability obfuscation has not yet reached reasonable levels, let us now discuss security and efficiency of current practical white-box implementations.E.g., the winner of the first white-box competition [ECR17] had a binary size of 17MB and needed 0.37 seconds for an encryption which is reasonably close to practical needs.It was broken eventually, but resisted key extraction attacks for up to 28 days [Riv17].This temporary robustness turns out to be indeed useful.Namely, in practice, the goal is to maintain a complexity gap between the effort of the attacker and the effort of the designer.As software can be updated in a regular interval, one can achieve a reasonable practical security level by replace a white-box implementation, in each update, by a newer generation.
Two considerations are important to be taken into account: (1) The whitebox implementation should not be susceptible to (variants of) automated attacks, since these can be implemented with little effort, see [ABBB + 19].(2) Reverse-engineering efforts against previous generations of white-box implementations shall not help the attacker against the new generation of the white-box implementation.I.e., the designer needs to come up with a paradigm that allows to systematically inject a certain amount of creativity into the system that needs to be reverse-engineered anew each time.For example, if security requires bootstrapping security from white-boxing another cryptographic primitive such as a PRF, then one can use a different PRF each time, harvesting the large cryptographic research of PRF constructions.In our model, we bind each payment application to a fresh hardware sub key, derived from a master hardware key, and we allow the adversary to see other derived hardware keys.This models that potentially, earlier construction might have been broken and might have revealed the derived hardware key in use.An alternative is to directly bind to a signature functionality so that revealing the verification algorithm does not constitute an attack vector.
Note that our models do not consider plain relay attacks [Han05,FHMM11] where the adversary forwards the intended communication without altering it.These attacks need to be prevented by other means, e.g., via distance-bounding protocols [ABB + 19], or at least mitigated via heuristics such as location correlation between phone and NFC reader [BKTS16].Note however that we of course capture attacks where, say, the adversary modifies user requests or tries to create new requests by himself.

Preliminaries and Notation
By a ← A(x), we denote the execution of a deterministic algorithm A on input x and the assignment of the output to a, while a ←$ A(x) denotes the execution of a randomized algorithm and the assignment of the output to a.We denote by := the process of initializing a set, e.g.X := ∅.By x ←$ X we denote the process of randomly and uniformly sampling an element x from a given set X. Slightly abusing notation, we also use x ←$ X to denote the sampling of x according to probability distribution X.We then denote the probability that the event E(x) happens by Pr x ← $ X [E(x)] or sometimes simply Pr[E(x)].We write oracles as superscript to the adversary A O .In cases when an adversary is granted access to a larger number of oracles, we write oracles also as subscript to the adversary A O1,O2 O3,O4 .PPT denotes probabilistic polynomial-time and poly (n) is an unspecified polynomial in the security parameter.Note that all algorithms receive the security parameter 1 n in unary notation as input implicitly.We write it explicitly only occasionally for clarity.We now review useful definitions, starting with nonce-based encryption, see Rogaway [Rog04].
Definition 1 (Symmetric Encryption).A nonce-based symmetric encryption scheme SE consists of a pair of deterministic polynomial-time algorithms (Enc, Dec) with the syntax c ← Enc(k, m, nc) and m/⊥ ← Dec(k, c, nc).The algorithm Enc takes as input a randomly generated key k of length n, a nonce nc, a message m, and outputs a ciphertext c.Dec takes as input a randomly generated key k of length n, a nonce nc, a ciphertext c, and outputs either a message m or an error symbol ⊥.Moreover, the encryption scheme SE satisfies correctness, if for all nonces nc ∈ {0, 1} n and for all messages m ∈ {0, 1} * , where the probability is over sampling k.
Definition 2 and Figure 1 specify the security of an authenticated encryption scheme [BN00,Rog02].Here, the adversary is provided with a left-or-right encryption oracle and a decryption oracle where it can submit arbitrary ciphertexts except for challenge ciphertexts obtained from the encryption oracle.If b = 0, the decryption oracle is functional.If b = 1, the decryption oracle always returns ⊥ which models ciphertext integrity.In the security game, we use assert as a shorthand to say that if the assert condition is violated, then the oracle returns an error symbol ⊥.
Definition 2 (AE-security).A nonce-based symmetric encryption scheme SE = (Enc, Dec) is called an authenticated encryption scheme or AE-secure if all PPT adversaries A have negligible distinguishing advantage in the game Exp AE SE,A (1 n ), specified in Figure 1.
Note that we demand the authenticated encryption scheme to be deterministic because we will later execute the algorithm in an untrusted environment and cannot count on strong randomness.This, in turn, implies that we cannot allow the adversary to re-use any of the previous queries (m, nc), or else it would be easy to determine b from two queries (m 0 , m 1 , nc) and (m 0 , m 1 , nc).
We provide a formal definition of a key derivation function that produces pseudorandom keys.Note that our definition corresponds to a PRF, i.e., it is highly simplified compared to the framework of Krawczyk [Kra10].In our definition a key derivation function takes as input a key k kdf , a context string e as well as the security parameter 1 n .In comparison to Krawczyk's definition, we simplify the presentation and omit the details of the smoothing step turning raw key material into random strings, the salting, and the length parameter, assuming that the key k kdf is already appropriate and the length of the returned key is equal to |k kdf |.Next we present the definition of a length-doubling pseudorandom generator.
Definition 6 (Pseudorandom Function).A deterministic, polynomial-time computable function PRF, such that PRF : {0, Puncturable PRFs (PPRF) were introduced by Boneh and Waters [BW13].PPRFs have a punctured key which allows to evaluate the PPRF on all inputs, except for one where the function still looks random.
Definition 7 (PPRF).A puncturable pseudorandom function scheme PPRF consists of a triple (PPRF, Punct, Eval), which are defined as follows: • PPRF(k, x) : This is a standard PRF evaluation algorithm.As before, this deterministic polynomial-time algorithm takes as input a key k and input x, both of length n and returns a value y of length n. • Punct(k, z) : This PPT algorithm takes as input a key k ∈ {0, 1} n and an input value z ∈ {0, 1} n .It outputs a punctured key punctured key k z and some input x ∈ {0, 1} n and returns ⊥ if x = z, and a value y ∈ {0, 1} n otherwise.
A puncturable PRF is said to be correct, if for all security parameter n, all k ∈ {0, 1} n , every value z ∈ {0, 1} n and all x ∈ {0, 1} n , x = z, it holds that PPRF security requires that the PPRF value on k and z is indistinguishable from random, even when given the punctured key k z .Note that for our purposes, we only rely on security for random inputs rather than adversarially chosen ones, i.e., we use a less powerful assumption which makes our result stronger.

Definition 8 (IND-PPRF-security).
A PPRF scheme is said to be IND-PPRFsecure if all probabilistic polynomial-time adversaries A have negligible distinguishing advantage in the IND-PPRF game defined in Figure 3.
An indistinguishability obfuscator (iO) ensures that the obfuscation of any two functionally equivalent programs (i.e.circuits) are computationally indistinguishable.In the following definition, a distinguisher D is an adversary that aims at identifying which of the two programs has been obfuscated.
is negligible in n and for all n ∈ N and all pairs (C 0 , C 1 ) in the range of A(1 n ), it holds that the size of C 0 and the size of C 1 is upper bounded by p(n).
Definition 10 (Indistinguishability Obfuscator).A PPT algorithm iO, parametrized by a polynomial p, is called an indistinguishability obfuscator if for any p-admissible circuit sampler S the following conditions are satisfied: Correctness.For all circuits C and for all inputs x to the circuit, where the probability is over the randomness of iO.Security.For all p-admissible S and any PPT distinguisher D, the following distinguishing advantage is negligible: where the probabilities are over the randomness of the algorithms.
When obfuscating cryptographic algorithms with keys it is often convenient to use the notation C[k](x) to denote the circuit with fixed encoded key(s) k and variable input x.

Hardware-Bound White-box Key Derivation Function
In this section, we first introduce our notion of a hardware module and explain how we instantiate it in our setting.Then, we provide the syntax and security notion for a hardware-bound key derivation function, present our construction and provide a security reduction to indistinguishability obfuscation and PPRFs.A schematic overview over the hardware module functionalities executed on the secure hardware is given in Figure 4. Namely, a hardware module comes with a key generation algorithm that generates the hardware master key k HWms .This key generation algorithm is run at the manufacturer of the hardware and thus not depicted in Figure 4.The secure hardware allows to export a sub-key via querying the secure hardware with a label .The hardware then runs the subkey generation algorithm SubKgen HW on k HWms and label and returns the resulting sub-key k HWsl .In addition, the secure hardware can be queried with a pair (x, label ).The hardware, then, uses the algorithm Resp HW to generate a PRF/MAC value σ for x under k HWms .In order to avoid storing k HWsl for all values label , the hardware re-derives k HWsl anew each time Resp HW is called.The PRF/MAC value can be checked outside of the secure hardware by running Check SW on k HWsl and the pair (x, σ).
Remark.For secure use of the hardware-binding, it is important that the verification key k HWsl is not stored in plain since, otherwise, one might derive PRF/MAC values using k HWsl rather than querying the hardware.Thus, the Check SW functionality will need to be white-boxed (and will later be bound to another functionality such as our white-box KDF), essentially making it asymmetric.Note that the syntax and correctness of our hardware module also allows to be directly implemented by a (standard, asymmetric) signature scheme such as provided by the Android Keystore [And18b].In that case, the verification key does not need additional protection.We chose to implement the hardware with a symmetric primitive for efficiency and simplicity of the proof.Note that regardless of whether one uses MACs or signature schemes as a hardware functionality, the verification functionality needs to be cryptographically bound to a software program to be useful; else the software program can be code-lifted and run without performing the verification check.
Regardless of efficiency, both approaches, using signature schemes directly or making MAC verification asymmetric, are sound approaches.Importantly, in both cases, the soundness of the approach relies on domain separation, i.e., signatures/MAC for one label should not be mixed up with signatures/MACs for a different label .Finally, recall that fixed device identifiers (that do not depend on the input x) tend to provide very weak hardware-binding guarantees only, since once intercepted, they can be emulated for a code-lifted software program.We now give the syntax for our hardware-module.
Definition 11 (Hardware Module HWM).A hardware module HWM consists of four algorithms (Kgen HW , SubKgen HW , Resp HW , Check SW ), where Kgen HW and SubKgen HW are PPT algorithms with the following syntax The algorithms Resp HW and Check SW are deterministic algorithms and have the following syntax Correctness requires that for all security parameters n ∈ N, where the probability is over the sampling of k HWms ←$ Kgen HW (1 n ).
We do not define or prove security of the hardware module as a standalone primitive, since we will later prove security of our white-box KDF directly based on the puncturable PRFs used in the hardware module construction.Note that a standalone security definition for a hardware module could not capture MACs/PRFs and signature security simultaneously.In our hardware module OResp(e) OSubKgen(label ) construction below, key generation samples a random key, sub-key generation applies a PRF to it to derive a sub-key, and Resp HW and Check SW essentially implement a PRF-based MAC.Note that the additional PRG evaluation in Check SW is merely used to enable the proof technique by Sahai and Waters [SW14].
Construction 1.Let PRG be a pseudorandom generator, PRF be a pseudorandom function and PPRF be a puncturable pseudorandom function.We construct a hardware module as follows: SubKgen HW (k HWms , label ) Resp HW (k HWms , label , x) 2 : return 1 else return 0 Hardware-bound White-box Key Derivation Function.We now define and construct a hardware-bound white-box key derivation function WKDF.We here build on the previously introduced hardware module and a traditional KDF.
In the compiling phase, a compiler Comp takes as input the KDF key k kdf and the sub-key k HWsl for Check SW .The compiler generates a program WKDF which takes as input a pair (e, σ) and, intuitively, first checks whether σ is valid for e under k HWsl and, if so, evaluates the KDF on k kdf and e.The role of the compiler, conceptually, is to return a program where the KDF operation is bound to the verification operation, i.e., the two functionalities cannot be separated from each other and the (outcome of the) verification cannot be manipulated.
Definition 12 (WKDF).A white-box key derivation scheme with hardware binding WKDF consists of a hardware module HWM, a key derivation function KDF, and a PPT compiling algorithm Comp: For all genuine k HWms , for all k kdf , for all e, for k HWsl = SubKgen HW (k HWms , label ) and σ = Resp HW (k HWms , label , e), we have Pr[KDF(k kdf , e) = WKDF(e, σ)] = 1 where the probability is taken over compiling WKDF ←$ Comp(k kdf , k HWsl ).
Security Model.We now define security for a WKDF via the IND-WKDF security game, illustrated in Figure 5.We want to capture the pseudorandomness of keys derived from the WKDF, i.e., an adversary should not be able to distinguish between a key produced from the WKDF and an equally long key sampled at random.As a white-box adversary, the game provides the adversary with the capability of inspecting the WKDF itself (i.e. its circuit or implementation code).
Recall that additionally, we want to capture the notion of hardware binding: if the adversary tries to run the WKDF without having access to its designated hardware, the WKDF should not be executable any more.We model this by giving the adversary hardware access via a OResp oracle, which the adversary queries by providing a context value e and which the adversary can query a polynomial number of times.With the reply σ from the hardware component, the adversary is able to run WKDF on the context value e used for querying OResp.Additionally, we grant the adversary access to an oracle OSubKgen.This oracle produces hardware sub-keys which might be used to generate new hardware-bound white-box key derivation functions.To avoid trivial attacks, the adversary is not allowed to request a sub-key under the same label that was used to generate the initial WKDF.
To capture the pseudorandomness of derived keys, the adversary has access to a real-or-random oracle OKDF.The oracle OKDF first samples a new context value e and then, depending on a random bit b, it either returns the output of the KDF (under key k kdf ) or a random string of equal length.To avoid trivial attacks, the adversary is not allowed to query the OResp oracle with the same context value that was sampled by the challenger.Finally, A outputs a bit b and wins if b = b.
Definition 13 (IND-WKDF).We say that a hardware-bound white-box key derivation scheme WKDF is IND-WKDF-secure if all PPT adversaries A have a negligible distinguishing advantage in game Exp IND-WKDF WKDF,A (1 n ), see Figure 5.
Note that one could also provide the adversary with a recompilation oracle [DLPR14] so that the adversary can request several (independent) copies of the WKDF based on the same key.We refrain from including this feature into our model, but note that our construction can be shown to achieve also this stronger notion, as indistinguishability obfuscation makes recompilation adversarially simulatable.

Construction of a WKDF
We now construct a WKDF, based on a traditional KDF and the previously introduced hardware module HWM.As discussed before, the compiler Comp, on input the KDF key k kdf and the hardware sub-key k HWsl binds the hardware Check SW procedure to the KDF evaluation.Concretely, the compiler constructs a circuit C[k kdf , k HWsl ] and obfuscates it using indistinguishability obfuscation.The circuit C[k kdf , k HWsl ], on input (e, σ) first checks whether Check SW (k HWsl , e, σ) equals 1.If yes, it returns the output of KDF(k kdf , e).Else, it returns the allzero string.The reason that the construction is secure, is, intuitively, that the obfuscation of C[k kdf , k HWsl ] achieves the desired binding property.We now first give the KDF construction and then the WKDF construction directly below.
Construction 2. Let PPRF be a puncturable pseudorandom function scheme, then we construct our KDF as follows: Let PRG be a pseudorandom generator, let PRF be a pseudorandom function, let PPRF be a puncturable PRF, and iO be an indistinguishability obfuscator for appropriate p-admissible samplers.Then Construction 3 is a secure white-box KDF scheme WKDF.
Overview: The proof is a hybrid argument over the number of queries q that A makes to the OKDF oracle which either returns the evaluation of a puncturable PRF or a random string of same length.Note that the proof applies the punctured programs approach by Sahai and Waters [SW14].Our hybrid games maintain a counter j that increases by 1 whenever the adversary queries the OKDF oracle.In the i-th hybrid the challenger returns a random string whenever the counter j > i, otherwise it returns the evaluation of the PPRF.In other words, whenever we move to the next hybrid, the oracle returns an additional random string such that we sequentially replace PPRF values by random strings of appropriate size.After at most polynomial steps we have replaced all OKDF outputs by random values and obtain Exp IND-WKDF A,1 (1 n ).
Detailed proof: Let q(n) be a polynomial strict upper bound on the number of queries that A makes to oracle OKDF.We define a sequence of adversary-dependent hybrid games Game 0 1 to Game (2) 18 game hops show that for 0 ≤ i ≤ q(n) − 1: Indistinguishability of Game 0 1 and Game then follows by a standard hybrid argument, guessing the hybrid index at random.We define the games and specify the game-hops below.The circuits are depicted on the right of this page.Equation 4 follows by inspection of the definitions of Game i 18 andGame i+1 1 .We now turn to showing Equation 3 which is the technical heart of the theorem.

OResp(e)
: assert e / ∈ Q : return y OKDF() OSubKgen HW (label ) OSubKgen HW (label ) OSubKgen HW (label ) We now reduce each game-hop to the underlying assumption.We omit boilerplate code for simulations and focus instead on describing the conceptual reasons why the reductions work.We only discuss the game-hops in the forward direction, since reductions in the backward direction proceed analogously.
Game 1 to Game 2. This game hop reduces to the PRF security of the PRF keyed with k HWms .We here rely on the fact that OSubKgen HW (label ) does not allow to query PRF(k HWms , •) on label .
Game 2 to Game 3.This game hop reduces to iO security and relies on the correctness of the PPRF.The correctness of the PPRF implies that the first two lines of C 1 and C 2 are equivalent, which allows to apply iO security.Note that the oracle OResp cannot be queried on z since z is added to Q in the very beginning of the game.Therefore, it suffices to use the punctured key k z in OResp.
Game 3 to Game 4. This game hop reduces to the IND-PPRF security of PPRF keyed with k HWsl and punctured at z.For the reduction, it is important to note that throughout the game, only punctured versions k z of k HWsl are used, except for calculating τ .
Game 4 to Game 5.This game hop replaces and relies on iO security.Instead of hardcoding τ into C 2 and computing y as PRG(τ ) within circuit C 2 , the value y = PRG(τ ) is directly hardcoded into circuit C 3 .As the two circuits are functionally equivalent, the game hop reduces to iO security.
Game 5 to Game 6.This game hop replaces y = PRG(τ ) by a randomly sampled value y.This game hop reduces to PRG security, since the variable τ that is sampled in Game i 5 (1 n ) is not used anywhere else in the game(s).
Game 6 to Game 7.This game hop reduces to iO security with an additional negligible statistical loss.In detail, the uniformity of the sampling of z from {0, 1} n ensures that, with overwhelming probability, the oracle OKDF does not return (e, * ) for a different than the ith query of A to the OKDF oracle, i.e., the change to OKDF yields a negligible statistical difference between Game i 6 (1 n ) and Game i 7 (1 n ).The more important change is the use of k z kdf in C 4 .Due to the correctness of the puncturable PRF, the circuits C 3 and C 4 are functionally equivalent and thus, this game hop can be reduced to iO security.
Game 7 to Game 8.This game hop reduces to the IND-PPRF security of PPRF, keyed with k kdf and punctured at z.For the reduction, it is important to note that throughout the game, only the punctured version k z kdf of k kdf is used, except for calculating k.
Game 8 to Game 9. Note that with overwhelming probability, y is not in the image of the PRG, since the image of the PRG is of size 2 n only, whereas y is sampled from a set of size 2 2n .Therefore, y is most likely outside the image of the PRG.If it is, then the circuits C 4 and C 5 are functionally equivalent as the if condition in the first line of C 4 cannot be satisfied by any input.Thus, this game hop reduces to iO security.
Game 9 to Game 10.Importantly, C 5 does not depend on k anymore and thus, it is perfectly indistinguishable for the adversary whether the OKDF uses k or an independently drawn value k that OKDF samples in the moment of the ithe query.
Game 10 to Game 18.These game hops are analogous in the backward direction.Note that k is not used in OKDF anymore in the game hops from Game 10 to Game 18.
Connecting the hybrids.We now show that Equation 4 holds, which we recall is On a high-level, Game i 18 and Game i+1 1 are identical since they both sample the first i + 1 keys in the OKDF oracle at random and compute the remaining keys using the PPRF.Note that Game i 18 and Game i+1 1 are only identical up to a negligible statistical difference since the pre-sampled value z is consumed at query i to the OKDF oracle in Game i 18 and only in query i + 1 in Game i+1 1 .However, as z is sampled uniformly at random from {0, 1} n , z remains statistically hidden from the adversary until it is returned as an output from the OKDF oracle.Thus, it is infeasible to determine when the pre-sampled value z was returned.We omit a detailed code-comparison, since it is quite simple.
Connecting the hybrids to the original game.Finally, we show Equation 1 and Equation 2. We start with the former which we recall is and Game 0 1 are identical since they both compute all keys in the OKDF oracle using the PPRF.Moreover, due to the correctness of the hardware module, it is functionally equivalent to use PPRF(k HWsl , e, 1 n ) and PPRF(PRF(k HWms , e, 1 n )) in oracle OResp.However, there is a negligible statistical difference between Exp IND-WKDF A,0 and Game 0 1 , since Game 0 1 pre-samples a uniformly random value z from {0, 1} n , while Exp IND-WKDF A,0 does not.However, as z is sampled uniformly at random, it remains statistically hidden from the adversary until it is returned as an output from the OKDF oracle.We omit a detailed codecomparison, since it is quite simple.The reasoning for Equation 2 is analogous.

Secure Payment Application
In this section we build a secure payment scheme, assuming an IND-WKDFsecure WKDF, as constructed in the previous section.As mentioned before, the main idea of the construction of the payment application is to bind a symmetric encryption scheme (that is only known to provide black-box security) on top of the WKDF via a layer of indistinguishability obfuscation and thereby bootstrap the security of the WKDF to the security of the symmetric encryption scheme and the entire payment application.We first introduce the syntax of a payment application, then present our construction and then turn to the security reduction for the construction.We now describe the process flow of an abstract payment application, illustrated in Figure 6.Note that this abstract payment application might also be implementable differently than assuming a WKDF.A payment application relies on a hardware module (see Definition 11), which we recall has a master hardware key k HWms , allows to derive sub-keys k HWsl ← SubKgen(k HWms , label ) from the master hardware key and allows to obtain MAC/PRF values σ ← Resp HW (k HWms , label , x) that can be verified outside of the hardware via the algorithm Check SW (k HWsl , x, σ) that returns 0 or 1.
As the payment application is bound to a hardware module, the user starts by deriving a hardware sub-key k HWsl ← SubKgen(k HWms , label ) in their hardware and transmit it securely to the server.In Figure 6, we hint at this secure transmission of k HWsl via an encryption under the server's public-key pk S .In our model, we later refrain from modeling this off-band transmission of k HWsl and simply assume that it is implemented securely.
The server then draws a symmetric key k pay for the user and binds it to the user's hardware sub-key k HWsl via the compilation algorithm Comp App : WPAY ←$ Comp App (k pay , k HWsl , P ).
The predicate function P restricts the set of valid messages that can be encrypted via WPAY.An example for useful restrictions are limits on the amount of the payment or hardcoding of the user's payment data.Note that potentially, P can also contain cryptographic functionalities (which we do not model).
As we consider a tokenized payment scheme, in addition to WPAY the server also generates several tokens, encrypts them under k pay and stores the encrypted tokens in an array Tokens that is indexed by token identifiers.It then transmits WPAY to the user, together with the array Tokens of encrypted tokens, see Figure 6.Now, the user can use WPAY to generate requests to the server.To do so, WPAY takes as input a message m as well as a pair of a token identifier id tk and its corresponding encrypted token etk .Conceptually, the goal of WPAY is to return a request req to the server that contains an encryption of m under the unencrypted token contained in etk .To facilitate verification on the server's side, the user's WPAY will also return the token identifier id tk : Importantly, in addition to the aforementioned inputs, WPAY also takes as input σ, which is a hardware value obtained from making an Resp HW query to the hardware for (label , id tk ).To ensure the hardware-binding, conceptually, WPAY needs to evaluate the algorithm Check SW (k HWsl , id tk , σ) internally and only perform the desired operations based on this check succeeding.Intuitively, the Check SW operation also needs to be bound to all further operations of WPAY.
Finally, upon receiving (id tk , req), the server retrieves the token tk corresponding to id tk and processes the request req via the algorithm Process.If the request is accepted, Process returns the message m that the client encrypted.Else, Process returns an error symbol ⊥.
Note that we require the server to know the secret key k pay to encrypt the tokens under k pay before sending it to the user.The advantage of this design is that the values of the tokens are not exposed before being stored.Note that we consider the server to be a trusted and secure party which is a necessary assumption: As the server is in charge of generating the tokens, the server knows the token values anyway.Thus, the server additionally knowing the value of the secret key k kdf of the user does not compromise the security of the mobile payment application from the perspective of the user.
Definition 14 (Hardware-Bound White-Box Payment Scheme).A hardware-bound white-box payment scheme WPAY is parametrized with a message length parameter (n) and consists of a hardware module HWM and the following algorithms: k pay ←$ Kgen pay (1 n ) : This randomized algorithm takes as input the security parameter and outputs the secret payment key k pay ; -(id tk , tk ) ←$ GenToken(1 n ) : This randomized algorithm takes as input the security parameter and returns a token tk and a token identifier id tk , where we assume that identifiers are unique with overwhelming probability; -(id tk , etk ) ←$ EnTok(k pay , (id tk , tk )) : This randomized algorithm takes as input a token tk together with its corresponding identifier id tk and outputs an encrypted token etk , together with its corresponding token identifier id tk ; -WPAY ←$ Comp App (k pay , k HWsl , P ) : This randomized algorithm takes as input a payment key k pay , a hardware-binding key k HWsl and a message filtering predicate P : {0, 1} Moreover, we require that the following correctness property holds: For all keys k pay , for all master hardware keys k HWms , for all pairs of tokens and token identifier (id tk , tk ), for all predicates P , for all messages m ∈ {0, 1} (n) such that P (m) = 1, for σ = Resp HW (k HWms , label , id tk ), it holds that where the probability is taken over compiling WPAY ←$ Comp App (k pay , k HWsl , P ) and encrypting the token (id tk , etk ) ←$ EnTok(k pay , (id tk , tk )).

Security of White-Box Payment Applications
We now specify security of a white-box payment application scheme WPAY.
Correctness of WPAY ensures that when having access to the hardware, the application WPAY is useful to generate payment requests.In turn, hardwarebinding security ensures that when not having access to the hardware, then the application becomes useless.In other words, in absence of the hardware, the adversary cannot generate new requests and does not learn anything about the content of the requests sent to the server.Thus, the desired security properties in the absence of the hardware are the following: (1) Integrity of the requests transmitted from user to server.
(2) Confidentiality of the messages contained in the requests transmitted from user to server.
We capture both properties via the IND-WPAY security game, depicted in Figure 7. IND-WPAY starts with a setup phase where the relevant keys are sampled, first for the hardware (line 3 and 4) and then for the payment application (line 5).Then, WPAY is compiled (line 6).Note that we allow the adversary to choose the filter function P , modelling that security should hold for all possible filter functions.We also allow the adversary to choose the hardware label .In practice, neither P nor label are adversarially chosen, but giving this ability to the adversary in the setup phase only makes our model stronger.Note that we consider our adversary as stateful, i.e., the adversary in the setup phase (line 2) shares state with the adversary that accesses oracles (line 7) in order to find out the secret bit b.As the adversary is a white-box adversary, it receives the compiled WPAY as input (line 7).We now turn to the explanation of the oracles.
Oracles OResp and OSubKgen model the adversary's hardware access.Upon querying OResp, a pair of token and its respective identifier are sampled at random.The value of the token identifier is used for generating the hardware value σ, and the oracle returns all three values.The adversary is thus able to run their own WPAY to generate a request message for that specific token, token id and hardware value.
OSubKgen lets the adversary observe hardware sub-key values.Such values could be values used by different applications or values from older versions of a payment application.To avoid trivial attacks, the adversary is not allowed to obtain the sub-key k HWsl that was used for compiling the white-box application WPAY (line 6 in the main Exp IND-WPAY WPAY,A procedure).Oracle OGetTok models generation and encryption of the tokens on the server's side and storing them in a list.We recall that a white-box adversary might be able to access the encrypted tokens stored on a user's phone and thus, OGetTok returns the encrypted token and its identifier to the adversary.
We now turn to the two remaining oracles that encode the desired security properties of confidentiality and integrity.We start with the transaction oracle OTransaction, which encodes the confidentiality property.On a conceptual level, OTransaction plays a similar role as the left-or-right encryption oracle in the security game for authenticated encryption (c.f.Definition 2): It encrypts either the left or the right message, depending on whether the secret bit b is 0 or 1. Upon submitting the two messages to the OTransaction oracle, the oracle randomly samples a pair of a token and its respective identifier and the token value is encrypted via the EnTok algorithm.The oracle then generates the necessary hardware value σ based on the sampled token identifier, and then generates a request message based on the token identifier, the encrypted token, the value σ and one of the two messages submitted by the adversary.The oracle then saves the generated request on a list C and returns the token identifier, the encrypted token and the request message.
Note that the adversary is not able to use their own app to generate the same request message received by the transaction oracle.Namely, while the adversary is able to choose which message to encrypt with their own app, the token used for encrypting the message is chosen at random and only with negligible probability will both request messages look the same.
The process oracle OProcess encodes the integrity of the request messages similarly to the decryption oracle in authenticated encryption.The adversary can submit arbitrary values as long as those were not obtained from OTransaction (check if they are in the set C) or if they were not generated using an id tk generated by the OResp oracle for generating the hardware value σ.The server retrieves (line 3) the token tk corresponding to id tk from the token list, decrypts (line 4) the request req with id tk and tk using the Process algorithm and deletes tk from the token list.Authenticity is modeled by only returning the message to the adversary if b = 0 and returning an error if b = 1.Thereby, the adversary is able to learn the secret bit b whenever the adversary is able to forge a fresh request.
Remark.Note that many useful properties are implied by our security definition.For instance, IND-WPAY security implies that the token values remain secret, unless the adversary queries the hardware on id tk .
Definition 15 (IND-WPAY Security).A hardware-bound white-box payment application scheme WPAY is said to be IND-WPAY-secure if all PPT adversaries A have negligible distinguishing advantage in the game Exp IND-WPAY WPAY,A (1 n ), specified in Figure 7.

Construction of White-box Payment Scheme
We now construct a white-box payment scheme WPAY, which is IND-WPAYsecure (see Figure 7), assuming the IND-WKDF-security of a white-box key derivation function WKDF (see Figure 5).We first give an overview of the algorithms of our construction.First, Kgen pay randomly samples a payment key k pay and the GenToken algorithm randomly samples a token tk and its respective identifier id tk .EnTok encrypts a token tk in the following way: For each token with the identifier id tk , it generates a key k ← KDF(k pay , id tk ), and uses an authenticated encryption scheme to encrypt the token using k.I.e., each token is encrypted using a different key.Note that each key is generated based on the same key k pay , but based on a different context value id tk since each token has a unique identifier.
The compilation algorithm Comp App of the payment scheme takes as input a payment key k pay , a sub-key value k HWsl as well as a message filtering predicate P .It uses the compilation algorithm Comp of the WKDF and runs it on (k pay , k HWsl ) to obtain a hardware-bound white-box program WKDF.It then runs indistinguishability obfuscation on a circuit C[WKDF, P ] and returns the output of the obfuscation as WPAY.The circuit C[WKDF, P ] and WPAY provide the same functionality, but in WPAY, due to the layer of obfuscation, the different operations cannot be separated anymore.C[WKDF, P ] takes as input a pair (id tk , etk ) of an encrypted token and its token identifier as well as a hardware value σ and a message m.It first runs WKDF on (id tk , σ) to obtain an output k, and recall that the security of WKDF ensures that k is only a KDF (and not an error value) if σ is the correct hardware value that yields Check SW (k HWsl , id tk , σ) = 1.Thus, the hardware-binding of WPAY is directly inherited from the hardware-binding of WKDF.Now, C[WKDF, P ] uses k to decrypt the etk (line 3), checks whether P (m) = 1 (line 4) and, if so, encrypts the message m using the token tk as key Fig. 8. Construction 4 of a WPAY scheme (line 5-6) and returns the resulting ciphertext as a request message req (line 8).Note that in the construction, we need to avoid the use of randomness, since we cannot rely on the randomness being honestly generated.Thus, we use a nonce-based encryption scheme, and the nonce nc used for encryption of the token is not only retrieved (line 2) for decryption of the token (line 3), but also re-used for encrypting the request (line 6).Note that the nonce in etk is not malleable since we encrypt the tokens with an authenticated encryption scheme which provides ciphertext integrity.
Recall that WPAY returns not only req but also the token identifier id tk of the token that was used to encrypt m.This is because the use of tk authenticates the user towards the server which, on its side, retrieves the token tk corresponding to id tk , and runs the Process algorithm on (req, tk ) which decrypts req with tk and returns the result.Construction 4. Based on two authenticated encryption schemes (Enc 1 , Dec 1 ), (Enc 2 , Dec 2 ) and the WKDF in Construction 3, we construct a white-box payment scheme with hardware binding WPAY = (Kgen pay , GenToken, EnTok, Comp App , Process), see Figure 4.2.
We provide a proof of the following theorem in Appendix A. (1 n ) at most by a negligible amount.
For the following proof overview, observe that in the IND-WPAY game, only the OProcess oracle and the OTransaction oracle depend on the bit b.Namely, OTransaction encrypts m b , and OProcess implements ideal authentication if b = 1 by simply rejecting all adversarially generated requests.
On a high-level, the security proof proceeds as follows.
(1) We replace all keys generated by the WKDF with random keys in OTransaction and OGetTok and reduce this game hop to the security of the WKDF.(2) In the OTransaction and OGetTok oracles, instead of encrypting the tokens tk with SE 1 , we encrypt 0 |tk | .To do so, we make a hybrid argument over the number of queries that the adversary makes to OTransaction and OGetTok and for each such query make a reduction to the AE security of SE 1 .(Note that IND-CPA security would suffice here, since the game provides no decryption oracle for SE 1 ).(3) In the OTransaction oracle, instead of encrypting m 0 , we now encrypt m 1 .At the same time, in the OProcess oracle, we do not perform encryptions anymore but rather answer all adversarial queries by ⊥.This proof again proceeds via a hybrid argument over the number of queries to OTransaction and OGetTok, since one token value is generated in each of these calls and we need to reduce to the security to each of them.( 4) We now de-idealize SE 1 again and encrypt the real token values.(5) We de-idealize the WKDF.
Proof.We now provide formal descriptions of the game hops implementing step (1), ( 2) and (3).Step ( 4) is analogous to step (2), and step ( 5) is analogous to step (1).Below, Game 1 is Exp IND-WPAY WPAY,A (1 n ) with bit b hardcoded to b = 0. Note that due to the length of the game, the description is split over two pages.Also recall that we measure the probability that the adversary returns 0, i.e., instead of returning (b = b * ), the game only returns b * .This is possible by a standard transformation on advantage terms with a loss of a factor of 2. Game 2 is Exp IND-WPAY WPAY,A (1 n ) with Construction 4 inlined and OTransaction uses the code of C[WKDF, P ] directly rather than using the corresponding obfuscated version.This replacement is justified, as the indistinguishability obfuscator preserves perfect functional equivalence between the obfuscated and the unobfuscated program.From Game 2 to Game 3 , in the OResp, we use WKDF instead of KDF which is justified by the correctness of WKDF.Moreover, in the OTransaction oracle, we do not recalculate k, as the correctness of WKDF ensures that WKDF and KDF compute the same key.Game 4 to Game 5 We need to reduce this game hop to the AE-security of SE 1 .We carry out a hybrid argument over the number of queries to OTransaction and OGetTok.Note that this is possible, because these oracles use uniformly random values to key SE 1 and these values are not used at other points in the system.
Game 5 to Game 6 We need to reduce this game hop to the AE-security of SE 2 .We carry out a hybrid argument over the number of queries to OTransaction and OGetTok.Note that this is possible, because these oracles use uniformly random values to key SE 2 and these values are only used in OTransaction, OGetTok and OProcess.Second, note that the nonces used for each encryption are randomly generated token identifiers id tk .Therefore, the restriction given in line 4 of the Transaction oracle in the IND-WPAY-game corresponds to the second line of the encryption oracle in the AE game.This means that an adversary in the IND-WPAY has the same restrictions for encrypting a message as an adversary in the AE game.Additionally, the process oracle only accepts request messages that were generated via the Transaction oracle.This restriction aligns with the restriction of the decryption oracle in the AE game.

3. 1 Fig. 4 .
Fig. 4. Functionalities of the hardware module performed in the hardware.The Check operation is performed by the software program corresponding to the label value.
1} n 2 : return kkdf KDF(k kdf , e) 1 : k ← PPRF(kkdf, e) 2 : return k Construction 3. Let iO be an indistinguishability obfuscator.Based on the hardware module HWM given in Construction 1 and the key derivation scheme KDF given in Construction 2, we construct WKDF by defining the following compiler Comp:

WPAYFig. 6 .
Fig.6.Diagram of our payment scheme.The hardware calculates the value σ via the EvalHW function on input id tk , the label and the master key.WPAY executes the CheckSW function on input σ and on the sub-key and id tk .

Theorem 2 .
Let (Enc 1 , Dec 1 ) and (Enc 2 , Dec 2 ) be two AE-secure symmetric encryption schemes, let WKDF be a IND-WKDF-secure white-box key derivation scheme, and let iO be an indistinguishability obfuscator for appropriate padmissible samplers.Then the white-box payment scheme WPAY in Construction 4 is IND-WPAY-secure.A Proof of Theorem 2Let A be a PPT adversary.Let Exp IND-WPAY A,0 (1 n ) denote the IND-WPAY game with b = 0 hardcoded and let Exp IND-WPAY A,1 (1 n ) denote the IND-WPAY game with b = 1 hardcoded.We need to show that A has negligible distinguishing advantage, i.e., that the probability that A returns 1 in Exp IND-WPAY A,0 (1 n ) differs from the probability that A returns 1 in Exp IND-WPAY A,1

Game 3 to
Game 4 We need to reduce this game hop to the IND-WKDF-security of the WKDF.The reduction receives (P ) from the adversary A and passes on label to the IND-KDF game.It then receives WKDF from the IND-WKDF game and computes WPAY ←$ iO(C[WKDF, P ]) and returns WPAY to A and then simulates its oracles and returns the same bit as A. To simulate the OGetTok and the OTransaction oracle, the reduction uses its OKDF() oracle.As all oracles sample the input to the key derivation function uniformly at random, the simulation is sound.Moreover, the reduction uses the OResp oracle of the IND-WKDF game to simulate the OResp oracle of the IND-WPAY game.Note that the assert condition is, with statistically overwhelming probability not violated, because the inputs are chosen at random by the reduction to simulate the OResp oracle of the IND-WPAY game.The reduction knows the token values and, thus, can simulate OProcess perfectly.Finally, the reduction uses OSubKgen to simulate OSubKgen by simply forwarding queries.
(n)→ {0, 1}.It outputs a white-box payment application WPAY with syntax (id tk , req) ← WPAY(id tk , etk , σ, m), where σ denotes a hardware value σ, m ∈ {0, 1} (n) denotes a payment message, and req constitutes a payment request; m ← Process(id tk , req, tk ) : This deterministic algorithm takes as input a token identifier id tk , a token value tk and a a request req.It outputs a message m or ⊥.