Crunchfish: Enabling Offline Payments in an Online World — Practical Guides to Offline Payment
Posted on Aug 25, 2023 by Joachim Samuelsson, CEO, Crunchfish
Despite all the recent attention on the topic of offline payments, there remains an unclear understanding in the market around the practical design choices and trade-offs for offline real-time payments and CBDCs. Crunchfish, a pioneer for offline payments, have been sponsoring a series of white papers written by Lipis Advisors with the objective to describe the imperative for offline payments and provide an overview of the various design considerations for payment system operators. This article provides a summary of the main points from the first four white papers on the topics of offline payment design, security, privacy, and interoperability. Two additional white papers are planned for 2023, with a focus on scalability in August and implementation issues in November.
Offline Payment Design
There are many reasons why payment system operators should be thinking about how to allow offline payments for real-time payment systems and future retail CBDCs. These include greater financial inclusion, improved payment system resilience, and higher levels of user convenience, trust, and privacy. Various use cases for offline payments are being tested worldwide by central banks, payment system operators, financial institutions, and tech providers. However, there is still a lack of understanding among such players regarding what models for offline payments exist as well as potential use cases.
Offline payments have previously been understood as a transaction that is recorded offline and processed at a later point in time. However, defining what makes a payment offline is not as straightforward as it might seem. Some industry experts would define it as a transaction that occurs between users without an internet connection. Payments made using non-internet servers, such as telecom servers, would fall under the definition of “offline.” Others counter that a transaction can only be considered offline if it occurs “without a connection to any external power source, non-internet server, or general ledger.”
Under this definition, offline transactions typically occur using hardware-based instruments that usually exist on either stored-value cards or smartphones. The devices communicate with each other, either manually or by using near-field communication (NFC), without the need for reconciliation with the online ledger for settlement. While experts might disagree about definitions, this is not highly relevant. Practically speaking, the characteristics of offline payment systems will vary depending on the operator’s specific aims and requirements. Certain payment system operators may find that online connectivity after every transaction is adequate, while others may prefer functionality that allows for consecutive offline payments after a limited number of transactions or value threshold.
Similarly, in some models of offline payments, both the payer and payee can be offline, and in other models, only one can be offline for the transaction to be successful. In models where an intermediary is required to settle the transaction, the offline element need not only be on the side of the payer/payee, but also on the side of the remitting bank, infrastructure, or other third parties.
In designing for offline payments, it is important to note that the main design choices are agnostic to the underlying online payment rail. The main design choices are instead related to the type of security protocol of the offline transaction (native layer-1 vs. non-native layer-2) as well as the trusted environment of the payer’s bearer application (hardware-based vs. software-based). This distinction is illustrated in Figure 1.
Online Payment Rail: Token-Based or Account-Based
Offline capabilities can be enabled for token-based payment rails (e.g., all cryptocurrencies and some CBDCs) as well as account-based rails (e.g., all real-time payment systems and some CBDCs). Central banks have a distinct choice when implementing digital cash. They may either base it on digital money by choosing an account-based payment rail implementation and enable digital money to work offline just as cash, or alternatively base it on physical cash by representing the physical banknote digitally and implementing a token-based payment rail between the central bank and banks as intermediaries.
Offline Security Protocol: Native Layer-1 vs. Non-native Layer-2 Tokens
A security protocol for offline payments serves the purpose of addressing the various security risks by ensuring the integrity and authenticity of the offline transaction. There are generally two design options for such a protocol. First is a native layer-1 solution, where the offline payment solution uses the same native security protocols as the underlying payment service. Alternatively, offline payments can be implemented using a non-native layer-2 security protocol, where tokens are signed out by debiting a locally held offline balance. A non-native layer-2 solution can be integrated with any type of payment rail and general ledger as the offline security protocol can be interoperable with any underlying payment system.
Layer-1 and layer-2 solutions are commonly used by cryptocurrencies to augment the crypto payment system with higher throughput. Similarly, offline payment systems implemented as either layer-1 or layer-2 solutions augment the underlying payment service with resilience and other desired features by enabling it to function offline as well.
Payment systems, especially CBDCs, must provide the same level of personal integrity as paying with cash. It is still possible to balance integrity with AML and tax evasion by imposing transaction limits on offline wallets not subject to full KYC. A layer-2 security protocol separate from the underlying online payment rail is therefore much preferred. This provides privacy-by-design, in contrast to an unacceptable surveillance-by-design.
Offline Trusted Environment: Hardware vs. Software-based
The second major design choice for offline payments relates to the nature of the Trusted Environment where the offline application can execute in a separate, secure environment in which the security protocol is being carried out. Such environments can be either hardware- or software-based.
Hardware-based protocols involve the use of physical devices to facilitate transactions without an internet connection, allowing them to perform payment processing tasks and store data locally or using non-internet servers. Software-based protocols, on the other hand, involve the use of software applications on a smartphone. In terms of scalability, hardware-based offline payment systems can typically handle a large volume of transactions without requiring an internet connection or external infrastructure. However, the production and distribution of physical devices, also known as Secure Elements (SE), can make this approach relatively more expensive to implement and maintain. Software-based trusted environments, on the other hand, do not require the distribution of physical components and may be updated more easily over the air.
Smartphones are the dominant bearer for payments today. In the future it is likely that smart glasses will play the same role. As it is not possible that all should be forced to use devices with the same hardware when it comes to smartphones or smart glasses, its trusted environment must be software-based. For financial and digital inclusion there is a need to deploy Digital Cash applications on cards, wearables, and feature phones as well. These hardware-based trusted environments are peripheral bearers that need to be able to exchange digital cash with the smartphone as the main bearer, even in full offline mode.
Offline Payment Security
Having gained a better understanding of the design elements of a secure offline payment system, we next discuss the specific security risks and mitigation at each level of the system architecture. One of the key risks in an offline payment scheme is double-spending. There are many types of attacks that might lead to double-spending, for example, man-in-the-middle attacks, transaction replay, cloning, jailbreaking, and tampering with the bearer application.
Some of the major security threats that can occur at the level of bearer application (e.g., smartphone, feature phone, wearable device, card, etc.) include tampering with the trusted application or its data. There is also the risk of cloning if the device is jailbroken or rooted, which enables a reset of the offline balance to prior levels. Although it is always possible to discover fraudulent cloning when the payer goes online, it is important to mitigate against rollbacks if the payer stays offline by imposing additional risk limits on transactional amounts. Cloning between devices is commonly mitigated via device fingerprinting, which ties the offline trusted application to the device on which it is running. Unauthorized access may be mitigated using Additional Factor Authorization (AFA) based on passphrases or biometrics to access the offline trusted application, for example. The trusted environment also protects against overdrafts and ensures that imposed risk limits by the issuer and the regulator are followed.
At the level of the offline payment messaging scheme, the risk of transaction replay and man-in-the-middle attacks — both manifestations of double-spending — must be mitigated. A transaction replay attack uses malicious apps to delay or intercept data transmission that occurs over a network. This information can then be processed and re-sent numerous times to effectively duplicate transactions. Even though it is relatively simple for hackers to carry out replay attacks, offline payment messaging schemes offer preventive measures for these attacks using timestamps and challenge requests and by positioning bookmarks in the new local ledger. Targeting the connection between the two parties is an alternative to directly attacking the integrity of the offline payment, with a man-in-the-middle assault the most typical method of doing this. In such attacks, the payer application and the payee application believe that they are communicating directly with the intended end point, but the attacker is intercepting and/or modifying the communication in the middle.
All cryptographic systems that are secure against man-in-the-middle attacks use two means: authentication and tamper detection. While an SE approach can provide tamper detection, authentication of the transactions can be ensured using public key infrastructure (PKI). While PKI is widely used on the internet today, it relies upon cryptography that is believed to be secure given the computational power available today and in the medium term. However, today’s cryptographic schemes will eventually be broken by a quantum computer. This will rapidly accelerate the irrelevance of today’s security systems and will have a dramatic impact on all sectors of the economy. To address this, there are plans to update the security algorithms with longer keys and signatures so that quantum computers cannot break them. However, for offline payments this is not viable due to limited bandwidth and storage capacity offline. To ensure integrity of offline payments when quantum computers are available therefore requires using a quantum-secure cryptographic key as a shared secret.
Even if protection against double-spending must be provided at the transactional level in an offline payment scheme, there should nevertheless be a seamless integration with the online general ledger where double-spending can also be discovered at the time of reconciliation between the offline and online ledgers. Offline payment solutions should therefore have adequate backend protections, such as certificate revocation, to ensure that the risks arising at the time of reconciliation are effectively addressed. It is also possible to deploy measures like those used in securing online payment systems, like behavioral biometrics and certificate expiration, etc. Last, the risk of loss and fraudulent use of offline payments can be reduced by imposing risk limits on offline wallets. These limits can be linked to KYC levels, higher limits for full KYC compliance, and lower limits for partial KYC-compliant customers. Such limits could be imposed by the issuer or driven by regulatory mandate.
Privacy Considerations
Offline payment implementations can offer different levels of privacy depending on the anonymity of the wallet and the nature of reconciliation with the online ledger. However, fully anonymous offline payments would pose numerous challenges from a compliance perspective, as CBDCs would still need to comply with existing KYC/AML regulations.
In the previous white papers, we discussed whether the offline security protocol was native layer-1 or non-native layer-2. The choice of offline security protocol is also a highly relevant design choice that will impact the privacy features of the offline payment system. In building an offline payment system designed to complement an account-based online rail, for example, a layer-1 offline protocol may limit privacy from the system operator as offline transactions would be subjected to the same degree of transparency as the online transactions. In contrast, offline payments based on a non-native layer-2 protocol would potentially allow for greater privacy for users given that the security protocol is separate from the online payment scheme. In this instance, the level of privacy would be comparable to withdrawing money from an ATM; the sender signs out funds through the debiting of a locally held offline balance. Only adjustments to balances are reflected on the online ledger.
Interoperability
To avoid having payment services in incompatible silos it is important to ensure interoperability. To accomplish this, the e-wallets must guarantee the payer’s intent to pay and that the debit is cleared before sending the payment to the recipient on the backbone rail. Front-end offline payments applications have a Security Association (SA) with a private key and a certificate with the associated public key.
Many offline systems rely on hardware-based, layer-1 solutions, where the payer uses the receiver’s public key for application-level encryption. However, hardware-based trusted environment, layer-1 solutions and their encryption schemes are typically proprietary and hinder interoperability. Crunchfish propose instead using an interoperable software-based trusted environment with a layer-2 solution using PKI-based signatures that implements an application and communication network-agnostic Trusted Application Protocol (TAP).
All payment applications could augment their service with the TAP. Although today’s payment services are reliant on the robust internet protocol, a payer has no use of the payment service without internet access. TAP facilitates instant settlement as well if the payment rail is open, making TAP ideal as the underlying protocol for interoperable payment services. The TAP header contains at least the signature of the application data using the private key of the payer. The extended application data payload may then be sent and verified at any node in the system having access to the same CA-root certificate, regardless of whether it is sent remotely using TCP/IP, VPN, or telecom to a host server or locally to a payment application over WiFi, LAN or in proximity. Whereas online payment schemes lack survivability in the face of failures, the TAP is designed to cope despite temporary failures on any link or node at the moment-of-payment.
Keep Up to Date
Stay tuned for the release of the Scalability whitepaper, coming in late August, and sign up for the webinar to accompany the paper’s release, scheduled for 1 September.
About Crunchfish
Crunchfish are a deep tech company developing a Digital Cash platform for Banks, Payment Services, and CBDC implementations and Gesture Interaction technology for AR/VR and the automotive industry. Crunchfish are listed on the Nasdaq First North Growth Market since 2016, with headquarters in Malmö, Sweden and a subsidiary in India.