GOOGLE PROPRIETARY AND CONFIDENTIAL
Google Pay Security Paper
Version 2.4 | January 2022
1.0 Introduction and Scope 2
2.0 Definitions 2
3.0 Android Security 3
3.1 Overview 3
4.0 Host Card Emulation Overview 4
5.0 Secure Limited-Use Key Storage 4
5.1 Context 4
5.2 Android security infrastructure & limited-use keys 5
5.3 Limited-Use Key Storage Approach 6
6.0 Android Device Lock as Cardholder Verification Method (CVM) 6
6.1 Context 6
6.2 Setup 7
6.3 Verification 9
6.4 Payment Authorization Approach 10
7.0 Secure Storage of CardHolder Data (CHD) on Google Servers 11
8.0 Device Attestation 12
8.1 How Device Attestation is Used 13
9.0 Key Management Infrastructure 13
10.0 Appendix 14
10.1 Pending Intent-based Memory Caching 14
10.2 FAQs 14
1
GOOGLE PROPRIETARY AND CONFIDENTIAL
1.0 Introduction and Scope
The purpose of this document is to describe the security model for Google Pay, a platform and
solution that gives users a way to easily make payments online, in stores and person to person
(P2P) using their Android device.
This paper focuses on security implementation and considerations for online and NFC payment
scenarios that use device tokens. The paper does not cover scenarios for non-tokenized
provisioning and payment transaction scenarios.
At a high level, the Google Pay security approach:
● Mandates the use of device attestation (handled by Google’s SafetyNet Attestation API )
1
to validate the security and compatibility of the device before allowing the provision or
use of payment credentials.
● Adheres to standards for payment network tokenization, the creation and use of a
cryptogram to represent payment credentials.
● Unlocks these cryptograms with limited-use keys (LUKs) or single use keys (SUKs),
which are stored in-memory on the device.
● Enables these keys for payments by leveraging Android device unlock as a Cardholder
Verification Method (CVM), rather than having to make a server-verified PIN entry.
2.0 Definitions
Host Card Emulation (HCE):
Android OS supports a method of card emulation that does not require a secure element, called
host-based card emulation. This system allows an Android application to emulate a payment
card and communicate directly to the NFC reader. For a detailed description of Host Card
Emulation, visit: https://developer.android.com/guide/topics/connectivity/nfc/hce.
Near Field Communication (NFC): https://developer.android.com/guide/topics/connectivity/nfc/
Secure Element: Many Android-powered devices that offer NFC functionality already support
NFC card emulation. In some cases, the card is emulated by a separate chip in the device,
called a secure element. SIM cards provided by wireless carriers may also contain a secure
element.
Service layer: Android API that select 3rd parties (e.g. card issuers) can invoke in their apps to add
tap-and-pay capabilities to their applications. Please note that the service layer never shares any
payment credentials of any kind with 3rd party apps that integrate it.
Limited Use Key (LUK): A key used to generate one or more cryptograms for a contactless
1
https://developer.android.com/training/safetynet/attestation
2
GOOGLE PROPRIETARY AND CONFIDENTIAL
transaction, usually limited by number of taps or expiration time/date.
Single Use Key (SUK): Serves the same purpose as a Limited Use Key but is used by some
Token Service Providers (TSPs) for one time use only.
Card Master Key (CMK): The primary key used to generate transaction cryptograms for
contactless transactions. In a cloud-based payments model, the Card Master Key (CMK) is
stored securely in the cloud, and used to generate Limited Use Keys that are stored in the
mobile payment application and used to generate transaction cryptograms.
CardHolder Data (CHD): Payments credentials that must be handled securely. For example, a
cardholder’s primary account number (PAN) is a CHD.
Trusted Execution Environment (TEE): a hardware isolated environment for running secure
code.
3.0 Android Security
Google Pay runs on the Android operating system, benefiting from its built-in security features.
Some of these features are automatically enabled and others can be leveraged to further bolster
the security of apps and services that run on Android. This section provides an overview of
Android security while subsequent sections describe how Google Pay implements additional
security features on this platform.
3.1 Overview
The Android operating system is designed with multi-layered security that provides the flexibility
required for an open platform, while providing protection for all users of the platform.
Android leverages traditional operating system security controls to:
● Protect user data
● Protect system resources (including the network)
● Provide application isolation
To achieve these objectives, Android provides these key security features:
● Google Play Protect to detect, alert and block on PHAs (potentially harmful apps) and
2
more features:
○ “Find My Device”, where a user can track their device from a browser and choose
to lock, erase or send a notification message to the device.
2
https://www.android.com/play-protect/
3
GOOGLE PROPRIETARY AND CONFIDENTIAL
○ “Safe Browsing” protection in Chrome, where a user is warned if the web site is
behaving suspiciously, allow them to get back to safety.
○ “Verify Apps API” which allows developers to check if Google Play Protect is
running on the device. Issuers/banks would benefit from using this with their own
apps that run on the Android platform.
● Platform security including SELinux protections, app isolation using sandboxing,
exploit mitigations, file-based encryption, Verified Boot and more
○ With the introduction of Project Treble in the Android Oreo release in 2017, it is
easier to update devices, give apps a way to verify Android devices, reduce
privilege, and mitigate sophisticated attacking techniques
● Open platform benefits with a community of defenders who collaborate to locate
vulnerabilities and develop mitigations with a magnitude and velocity that would be
difficult to match in a closed platform
● Device compliance requires that hardware OEMs follow the Compatibility Definition
Document (CDD) and certify against this using the Android Compatibility Test Suite
3 4
(CTS), all to ensure compliance with Android APIs
● Device attestation performed by Google APIs (like SafetyNet) enabling checks for basic
integrity, tampering (e.g. rooted device) and other indicators of compromise
These are but a few of the numerous features and benefits of the Android platform and
ecosystem. For more information on Android security, please visit the Android Security Center .
5
4.0 Host Card Emulation Overview
Many Android-powered devices that offer NFC functionality already support NFC card
emulation. In some cases, the card is emulated by a separate chip in the device, called a secure
element. SIM cards provided by wireless carriers may also contain a secure element.
Android 4.4 (KitKat) introduced an additional method of card emulation that does not involve a
secure element, called host-based card emulation. This system allows an Android application to
emulate a card and talk directly to the NFC reader.
A detailed description of Host Card Emulation is posted online .
6
6
https://developer.android.com/guide/topics/connectivity/nfc/hce
5
https://www.android.com/security-center/
4
https://source.android.com/compatibility/cts
3
https://source.android.com/compatibility/cdd
4
GOOGLE PROPRIETARY AND CONFIDENTIAL
5.0 Secure Limited-Use Key Storage
5.1 Context
Conventional provisioning of credit card information to a device (whether tokenized or not)
involves storing a Master Key on a trusted piece of hardware like a Secure Element. For the
purpose of this document, it will be called Card Master Key (CMK). CMK is synonymous with
Master Derivation Key (MDK).
The CMK serves as a long-term secret used to compute cryptographic dynamic verification
codes (CVC3) are generated for MSD transactions and ARQC (Online Authorization Request)
cryptograms are generated for EMV transactions. These are verified by the issuer during issuer
authorization.
Google uses “Cloud Based Payments” in which the CMK is stored in the Token Service
Provider’s servers and used to derive limited-use, or single-use keys . These limited-use keys
7
are sent to the device and used to compute CVC3 codes/ARQC cryptograms rather than using
the CMK directly. Note that a limited-use key may be able to generate the necessary
cryptograms for more than one transaction, depending on issuer and network preferences.
A security approach that Google does not use is to include a user PIN (set during mobile
payment setup) as an input to the cryptogram computation. In the Google Tap-and-Pay
experience, users authenticate payments by either waking up the phone or using device unlock
(for high value transactions) rather than a PIN that is specific to the service layer, so a
cryptogram that relies on a user PIN will not work. In this paper, we demonstrate how we can
store single-use keys in a manner that is sufficiently secure to avoid the need for a PIN-derived
cryptogram.
5.2 Android security infrastructure & limited-use keys
Android phones have several security properties that allow us to increase our confidence that
limited-use keys are being provisioned to the correct device, and that they cannot leave that
device and be used elsewhere. In particular:
● Strong app sandboxing: The memory and storage of apps is strongly separated, and
certified devices do not provide a mechanism for violating these constraints
● Locked bootloader: In order to install a new system image it is necessary to first unlock
the bootloader, which forces a userdata and memory wipe
● Security services: Google has deployed, to all Android devices with the Google Apps
suite, a set of services that can monitor security properties and protect against attacks
such as malware and known vulnerabilities
7
The duration of the keys and how many transactions they can sign will be determined by the payment network or
issuer. For brevity we refer to both limited and single use keys as "limited-use" in this document, as the former is the
more general term.
5
GOOGLE PROPRIETARY AND CONFIDENTIAL
● Device attestation: Google is deploying, to all Android devices with the Google Apps
suite, a software-based attestation API which deeply inspects the hardware and software
of the device to determine:
○ If the device is real, meaning not an emulator
○ If the device is of a type (hardware and system software) that is known to
Google, which implies knowledge of whether the device has passed Google’s
Compatibility Test Suite (CTS)
■ Passing CTS increases assurances that the device has not been modified
in ways known to break the Android security model (i.e. rooted, modified
system image, unlocked bootloader)
5.3 Limited-Use Key Storage Approach
We store both the relatively long-lived token (tokenized PAN) and limited-use keys encrypted in
persistent application storage. The LUKs will be encrypted at rest using symmetric AES
encryption. When a user first provisions a token to her wallet, Google servers will generate a
Device Encryption Key (DEK). This key will be used to encrypt and decrypt the LUKs on the
device. The DEK is stored on Google’s servers, and a copy is kept in the device’s memory. On
devices that support TEEs, an additional copy is kept in the TEE. When the device reboots, the
copy in memory is lost and the device must either restore the DEK from the TEE or by making a
call to Google’s servers.
When the service layer connects to Google servers to request the LUK encryption key or
additional LUKs, the server will request a device attestation. The attestation software will report
the state and identity of the device to Google, which will validate the CTS compatibility of the
device. See Section 8.0 Device Attestation API for more details on attestation.
Upon receipt of limited-use credentials from Google's server, the Tap-and-Pay service layer will
ensure that it has the decryption key for the LUKs stored in RAM. The limited-use key material
retrieved from the server will be encrypted using the DEK, and stored in the service layer’s sqlite
database.
When performing a transaction, the Android device will use the in-memory key to decrypt the
data retrieved from the service layer’s app database, and then use it to generate the transaction
cryptograms required by the contactless payment protocol.
If the on-device key is lost the device will request the decryption key from Google servers,
requiring device attestation.
Should a key rotation be necessary, the next time the device contacts the server to retrieve the
key, the server will generate a new key and provide both the old and new keys to the device so
that the device can rewrap its data and switch to the new key.
6
GOOGLE PROPRIETARY AND CONFIDENTIAL
6.0 Android Device Lock as Cardholder Verification Method
(CVM)
6.1 Context
To make NFC payments over HCE on devices running Android 5.0 Lollipop or higher Android
versions, a user must enable a secure lock mechanism on the device. This will ensure that a
secure lock is configured when enabling payments on the device, and before making each
transaction. To make a payment, a user wakes up the phone by powering on the device screen
and then tapping the phone against the NFC reader.
6.2 Setup
Android lock screens utilize a timeout model where the screen will lock after N seconds of
inactivity. The types of locks available are: none, slide, face unlock, pattern, PIN, password, and
fingerprint, iris scan & 3D Face unlock. The latter 6 are considered "secure," and there is an API
to programmatically verify that the user has selected a secure method.
8
After the screen turns off, there is a setting which controls how much time can pass until the lock
re-engages.
Here are screenshots of the configuration options, on several devices:
The lock settings are accessed from the Settings application's Security or Lock Screen menu:
8
https://developer.android.com/reference/android/app/KeyguardManager#isKeyguardSecure()
7
GOOGLE PROPRIETARY AND CONFIDENTIAL
Nexus 4 - Android 5.1
Samsung Galaxy S4 - Android 5.0
Pixel 3XL - Android 9.0
From the Security menu, the Screen Lock item allows the user to select an unlock mechanism.
Pattern, PIN,Password, Fingerprint, iris scan and 3D Face Unlock are considered secure
methods:
Nexus 4 - Android 5.1
Samsung Galaxy S4 - Android 5.0
Pixel 3XL - Android 9.0
From the Security menu, the Automatically Lock item allows the user to specify how long before
an inactive device is locked:
8
GOOGLE PROPRIETARY AND CONFIDENTIAL
Nexus 4 - Android 5.1
Samsung Galaxy S4 - Android 5.0
Pixel 3XL Menu - Android 9.0
In the event the user does not have a secure lock mechanism set at the time of transaction,
Android will not allow the transaction to proceed and will message the user accordingly:
Nexus 4 - Android 5.1
Samsung Galaxy S4 - Android 5.0
Pixel 3XL - Android 9.0
9
GOOGLE PROPRIETARY AND CONFIDENTIAL
6.3 Verification
Storage and verification of device locks is performed by the Android Gatekeeper. When a user
sets a new secure device lock, the lock sequence is managed by secure hardware and is
inaccessible to applications and the host operating system.
All pin / pattern / password prompts to the user are rate-limited (see screenshot below) to
prevent brute force attacks, and there is no programmatic way for an app or service to test a pin
/ pattern / password. Access to the code that verifies the pin / pattern / password is gated by a
special platform-only Android permission that requires the caller to be a part of the system
image.
10
GOOGLE PROPRIETARY AND CONFIDENTIAL
Screen preventing brute force guess attacks
6.4 Payment Authorization Approach
A key user experience principle is to have mobile payments be as frictionless as contactless
cards today. Today users are used to a Tap-and-Go experience with plastic cards, but they may
not be able to make High Value Transactions (HVT). The HVT limit is defined as the CVM limit in
country - it is not adjusted by Google Pay. With mobile, we propose a similarly frictionless
experience where the user must “wake up” the screen for a Low Value Transaction (LVT) but will
not be required to unlock the device. For HVTs, the user will have to unlock before they can
finish the transaction.
This approach has the following benefits:
● It leverages a mechanism the user likely already understands: many users (~60%)
already employ secure device lock policies to protect their sensitive personal data like
email and contacts. Using it to protect high value payments is a natural extension.
● The interaction with the Point of Sale will be natural: the user must turn on her screen in
order to pay (to enable the NFC radio). Unlock is only required for HVTs, so users can
easily Tap and Pay but there is additional protection in place for expensive purchases.
● The lock screen setup allows users to configure any timeout desired so a user can set a
short timeout i.e. 5 seconds, 15 seconds, etc, but still have a smooth transaction
experience without having to constantly unlock
11
GOOGLE PROPRIETARY AND CONFIDENTIAL
● Google may make the locking mechanisms more intelligent / secure over future releases
of Android. If we verify cardholder presence for payments using this mechanism we
stand to benefit from this future innovation.
● There is a transaction counter requiring the user to unlock for LVTs after three
transactions without an unlock.
When enabling Tap-and-Pay on a device, Google can display instructional content to make sure
users are aware of how they can configure their device locks to protect access to their device’s
payment capabilities. In addition, the software running on the phone will regularly check
(including at time of transaction) to ensure that the locking mechanism chosen is still secure.
The service layer will detect if the user has disabled a secure lock. Upon detecting that the user
has disabled a secure lock, the service layer will delete the user’s payment credentials from the
device unless the user re-enables a secure lock soon after disabling it. This lessens the
potential threat of a cardholder disabling her secure lock, a fraudster picking up the unlocked
phone, setting up a new secure lock, and then completing a contactless payment with the
phone.
7.0 Secure Storage of CardHolder Data (CHD) on Google Servers
Google has deployed a number of security measures to isolate and protect Cardholder Data
(CHD) in our server systems, including encryption in transit, encryption at rest, and tokenization
(not to be confused with network-specified PAN tokenization). These measures are certified
annually against the PCI requirements by a Qualified Security Assessor (QSA).
All user communication with the Google services is encrypted using HTTPS. Google uses
embedded filters in its EES (“Edge Encryption Service”) to strip off any CHD from incoming
requests. The CHD is encrypted by EES, using a public key whose private component is
generated and stored in a FIPS 140-2 level 3-certified Hardware Security Module and then
forwarded to Databunker (Google’s internal name for our PCI-certified secure environment)
where it is stored. The CHD is then referenced using a randomly-generated 128-bit token (which
we call a “SecureID”) generated by EES that replaces the CHD in the original user message.
This tokenization ensures that CHD is not passed to any Google servers that are not as secure
as the Databunker. The tokenized message is then channeled to the intended applications.
12
GOOGLE PROPRIETARY AND CONFIDENTIAL
Figure 2: Diagram of Google’s system for secure storage of cardholder data.
Subsequently, any in-flow process (the frontend and beyond the “fanout” referenced above)
passes the SecureID as a reference to the actual value stored in Databunker. When a service
running in the PCI Secure environment needs the actual value, it exchanges the SecureID for
the real value. This system and process is used in Google’s credit card authorization flow today.
8.0 Device Attestation
Device attestation makes a cryptographically verifiable statement about the Android device
hardware and system software. This increase our confidence in the enforcement of this security
model. In the context of payments, device attestation helps mitigate the risk of a malicious actor
stealing keys from the device.
Device attestation is powered by Google’s device attestation service which collects signals
using on-device software and sends the results to a Google server for analysis. The on-device
software is tamper-resistant and generated on-the-fly by the server, making it very difficult for
attackers to analyze, and very easy for Google to enhance as needed.
With this knowledge app developers can decide whether the device is capable of certain
security-sensitive features offered by the app by learning whether the device’s operating system
13
GOOGLE PROPRIETARY AND CONFIDENTIAL
is likely in its original state and complies with the Android security model.
Google ties its own identity and account management system to this attestation API, a
system which is critical to Google’s business model.
8.1 How Device Attestation is Used
Our solution uses device attestation to ensure that the device is valid and the Android security
model is intact at certain critical points of the flow. Performing these runtime checks helps to
increase our confidence that the security model is intact times prior to making sensitive
decisions.
Our solution will perform attestation before tokenizing a card on the device, and every time
LUKs are provisioned or refreshed to the device. This will reduce the likelihood of payment
credentials being provisioned to a compromised device. The service layer will also perform
attestation at least once per day to ensure that the device is likely in a safe state during
transactions.
In the event attestation fails, no transactions will be allowed and no keys or tokens will be
provisioned to the device.
9.0 Key Management Infrastructure
All applications on Android are signed using a private key maintained by the individual
developer. On a specific device, the Android platform is effectively a collection of applications
that are signed with a private key that is managed by the OEM for that device. Generally, there
is no relationship between individual developer keys and platform keys. Android uses the
signing key to isolate applications into distinct sandboxes and to ensure that application updates
are from the same source as the original application. The CDD has an explicit requirement that
all Android devices are able to install applications signed with any key.
The Android platform provides access to sensitive functionality based on a concept called
permissions. Applications that are signed with the platform key for a specific device are able to
access SystemOrSignature permissions based on that signature. All other applications are able
to access permissions at the level Normal or Dangerous based on notification provided to the
user. Applications may choose to expose Signature permissions that are then accessible to
other applications that are signed with the same key as the granting application.
Google’s practice as an OEM and application developer is that all private keys be held
exclusively in dedicated hardware security modules with appropriate process restricting access
only to final release builds. We use unique platform keys for each device for which we are the
OEM (Nexus/Pixel devices). Where possible, we use unique keys for each application – though
many Google applications are signed with a small set of shared keys in order to facilitate
inter-application communication protected by Signature permissions.
14
GOOGLE PROPRIETARY AND CONFIDENTIAL
We have communicated our key management practices as a recommendation to OEMs that
create Android devices, as well as to application developers.
10.0 Appendix
10.1 Pending Intent-based Memory Caching
To ensure that sensitive data is stored only in RAM but is guaranteed to survive until reboot,
rather than being evicted along with the Tap-and-Pay service layer in low-memory situations, we
will use a technique used by several other Google teams: sending a PendingIntent to the
service layer containing the sensitive data. Because PendingIntents are retrievable only by their
specified recipient, only the service layer will be able to receive the data. Because
PendingIntents are managed by a system service and available across recipient app restarts,
the service layer will be able to reliably retrieve the data until device reboot.
To minimize the amount of system RAM consumed and to add an additional layer of security,
the data attached to the PendingIntent will contain only an encryption key and an HMAC key.
The actual sensitive data will be encrypted and MACed with those keys and then stored in the
app’s persistent store. Thus, if the PendingIntent somehow leaked it would not contain anything
of value unless app sandboxing were also breached to allow access to the app’s persistent
store.
10.2 FAQs
1) Why are the chosen device unlock methods considered secure?
We use the Android API “ isDeviceSecure” which only returns True if the user has set a
strong unlock mechanism (PIN, pattern, password, fingerprint, iris scan or Face unlock). This
API is managed by Android’s security team who regularly review existing and emergent unlock
mechanisms for secure classification status.
2) How do velocity controls impact the security risk model?
Google tracks multiple conditions that help us better secure tokenization and ID&V related
operations, in addition to any network or issuer provided controls. Velocity controls are one such
element, giving Google information relating to recent actions on the user device. One example
is tracking whether a device has experienced multiple failed token issuance attempts.
3) Do you expect the CVM approach for remote payments to be the same as for
contactless transactions? (i.e. consistent user experience?)
In-app CVM will require an unlock during the previous 10 minutes. Please see examples of
CVM rules for some countries below
15
GOOGLE PROPRIETARY AND CONFIDENTIAL
Country
Low Value Transactions
(Under 25 Euro)
In-app
France
No unlock required,
Velocity check: 3 taps per
keyguard (screen locked)
Unlock required,
Up to 2 taps during
10 min since the
last unlock
Germany
No unlock required,
Velocity check: 3 taps per
keyguard (screen locked)
Unlock required,
Up to 2 taps during
10 min since the
last unlock
Poland
No unlock required,
Velocity check: 3 taps per
keyguard (screen locked)
Unlock required,
Up to 2 taps during
10 min since the
last unlock
UK
No unlock required,
Velocity check: 3 taps per
keyguard (screen locked)
Unlock required,
Up to 2 taps during
10 min since the
last unlock
Transaction Examples
11
“Successful” means that if we can detect an NFC tear - it will not count as a transaction and user may
tap again without additional unlock.
10
“Successful” means that if we can detect an NFC tear - it will not count as a transaction and user may
tap again without additional unlock.
9
“Successful” means that if we can detect an NFC tear - it will not count as a transaction and user may
tap again without additional unlock.
16
GOOGLE PROPRIETARY AND CONFIDENTIAL
1. User taps on a retailer’s terminal to make an NFC contactless transaction for 20 Euros
with screen on but device locked. No CVM is required, transaction continues with no
action further action required by user.
2. User taps on a retailer’s terminal to make an NFC contactless transaction for 50 Euros
with their device locked. CVM is required, user is prompted to unlock their device and
tap the terminal again to continue the transaction.
4) What are the minimum system requirements to run Google Pay?
Google Pay runs on devices with Android v5.0 Lollipop that support NFC/HCE and that pass
attestation.
5) What configurations are required by the user or OEM for Google Pay to work?
OS screen lock needs to be active to operate Google Pay. Otherwise, Google Pay has been
designed to work out of the box with no special configurations. This includes keys/certificates
management and payments bundles periodic replenishment.
6) Does Google Pay run on rooted phones?
Google Pay runs on devices passing attestation. The latter fails at a number of conditions
including those indicative of the execution of phone rooting tools.
7) Can Smart Unlock be used to authenticate Google Pay transactions?
Currently Google Pay does not support SmartLock. Smart Lock (aka Automatic Unlock) is an
12
additional layer on top of the secure keyguard (PIN, pattern, etc). The user will be required to
follow the CVM method defined.
8) What are the security assets managed by Google Pay?
The Google Pay client employs platform and custom security controls to protect the
confidentiality of Limited Use Keys (LUK), tokenized PAN (DPAN), DEK and the ICC Private
Key.
9) What is the maximum allowed incorrect attempts for unlocking the phone? What are
the controls to defend from PIN/pattern guessing?
For every incorrect PIN / Pattern or Password attempt there is an increasing delay before a PIN
/ Pattern or Password can be tried again.
If 'n' is the number of consecutive authentication failures, the delay imposed before the next
allowed attempt is given by the following piecewise function::
● 0 seconds, when 0 <= n < 5
12
https://support.google.com/nexus/answer/6093922?hl=en
17
GOOGLE PROPRIETARY AND CONFIDENTIAL
● 30 seconds, when n = 5
● 0 seconds, when 6 <= n < 10
● 30 seconds, when 10 <= n < 30
● 30 * 2^((n-30)/10) seconds, when 30 <= n < 140
● 86400 seconds (1 day) when n >= 140
So, the delay after the 40th consecutive failure is one minute, and it's four minutes after the 60th
failure. This means the cumulative delay to test a number of PINs (assuming zero time for PIN
entry, rounded to two significant figures) is:
40 PINs = 8.5 minutes
60 PINs = 53 minutes
100 PINs = 16 hours
150 PINs = 21 days
200 PINs = 2.4 months
300 PINs = 5.7 months
400 PINs = 9.0 months
500 PINs = 1.0 years
750 PINs = 1.7 years
1000 PINs = 2.4 years
2500 PINs = 6.5 years
5000 PINs = 13 years (expected time to brute force a four-digit PIN)
10) After fingerprint is largely adopted, is Google planning to support other CVMs (PIN,
pattern, password)?
Google Pay uses the Android API “isDeviceSecure” method to determine supported CVMs.
This includes touch as well as PIN, patter, password, fingerprint, iris scan and Face unlock.
11) What is the process behind deriving LUKs from CMKs? How will the issuer be made
aware of the latest LUK by the TSP (Token Service Provider)?
The derivation from CMK to LUK is owned by the TSP (Token Service Provider) and we don't
get involved in this process. At auth time, the issuer needs to call the TSP to detokenize and
validate the checksum based on the LUK.
12) Will the DPAN be stored encrypted along with the LUK in the service layer’s sqlite
database?
Yes. Each TSP provides a payment bundle which includes static data like the token and
dynamic data like the keys. The bundle data is stored encrypted on the device.
13) How doesGoogle handle rogue apps on the Play store/elsewhere perpetrating to be
Android based wallet?
18
GOOGLE PROPRIETARY AND CONFIDENTIAL
The Play store utilizes automated and manual review capabilities to detect and disable "fake"
apps. Monitoring addresses a number of characteristics, including name and icon. In addition,
Google takes action on fishing apps based on reports from users. Lastly, Android attestation
services monitor apps on the mobile device and report malware-like behavior for the abuse
team to conduct further investigation and potentially disable the app across the Android
platform.
14) Is the security in Android attestation services based exclusively in the on-device
software generated on-the-fly by the Google server?
It is a tamper-resistant downloadable, generated on-the-fly on the server side.
15) When/how does Google Pay delete user tokens?
Use cases where tokens are deleted are:
● user deletes token in Google Pay
● user wipes device using Android Device Manager
● user deletes GAIA / Google Payment account (Wipeout)
● user's device hasn't checked in with our servers in 90 days (see below for more details)
● issuer/network tells us to delete the token (could happen for a variety of reasons)
Regarding the 90 day deletion policy:
● The typical scenario is when the user purchases a new phone and then turns off their old
one, which had the tokens on them.
● Device ‘check in’ requires that the device be online and able to connect with Google
servers. A powered off phone won’t check in.
○ Check in happens once a day or can also be triggered by key replenishment.
○ Keys are issued by networks to unlock payment bundles on the phone, which are
used to make purchases in-store or in-app
● If a device does not check in within 90 days, Google marks this token as being deleted
and sends a request to the TSP to delete the token from their records. The TSP would
also notify the issuer of this action.
○ If the device tries to transact after this time period (e.g. device was in airplane
mode/offline), the issuer would decline the transaction.
○ Depending on the TSP, the keys may expire during this time, in which case the
payment attempt would fail well before reaching the issuer
● These safeguards to limit offline use of Google Pay are unlike many other wallet
19
GOOGLE PROPRIETARY AND CONFIDENTIAL
solutions, which allow ongoing use of tokens even when the device is offline.
Please note that deleting the Google Pay app does not remove the tokens/cards from the
device because they are stored in the service layer. The user will have to remove the tokens
before they delete the app or delete them through Google Pay in Android Settings.
16) Card Expiration and Token validity
Same PAN, new expiration date: Existing tokens are kept and are valid. Seamless
transition, user does not need to update card?
● This is a seamless transition and the user does not need to update anything. Google
uses the Account Updater service in the US which updates the expiration date of the
underlying card on file. The token has its own expiration date independent of the plastic.
Different PAN: Are existing tokens valid? Does the user still need to add the new card?
● This is also a seamless transition for the user and existing tokens are valid as long as
the issuer considers it valid. As long as the issuer subscribes to Account Updater in the
US, the last 4 of the card in Google Pay will be updated. Google Pay also supports PAN
Notification updates via TSPs (Token Service Providers).
The card is replaced prior to the expiration date. Assume fraud or breach, PAN is likely
different.
1. Issuer send Token Lifecycle event calls
Token is still valid as long as the issuer considers it valid. Google may get a new card
number on file though Account Updater, in which case Google Pay will show updated
last 4 digits. Google Pay also supports PAN Notification updates via TSPs (Token
Service Providers).
2. User is not aware, nor is Google. A transaction is attempted. Does it go
through?
Depending on the fraud scenario, the issuer may or may not honor the transaction.
17) Google Pay on Wear OS
Google Pay on Wear OS uses the same service layer and same data protection strategies that
is used on phones.
17) Code Obfuscation
Obfuscation in Google Play Services is primarily used to reduce the size of the binary and is not
relied on to be a security measure.
20
GOOGLE PROPRIETARY AND CONFIDENTIAL
21