This blog was made possible thanks to contributions from Nicola Bertoli, Sandra Grazia Tedesco, Alessio Di Michelangeli, Omri Soceanu, Akram Bitar, Allon Adir, Salvatore Sollami and Liam Chambers.

Intesa Sanpaolo is one of the most trusted and profitable European banks. It offers commercial banking, corporate investment banking, asset management and insurance services. It is the leading bank in Italy with approximately 12 million customers served through its digital and traditional channels.

The Cybersecurity Lab of Intesa Sanpaolo (ISP) needed to develop a sandbox to preserve the privacy of confidential information related to customers’ asset transactions during computation and in the bank’s system.

What if you could unlock the value of your sensitive data without ever having to decrypt it?

Well-designed software applications encrypt sensitive data when it is at rest or in transit. This provides robust protection of data in those states. However, to analyse or process data in memory, it needs to be decrypted. This creates a window of vulnerability for threat actors to potentially exploit. Unencrypted data in use could be susceptible to external and insider threats, including data theft. Using homomorphic encryption prevents this.

Homomorphic encryption differs from typical encryption methods by allowing computation to be performed directly on encrypted data without the need to decrypt it and without requiring access to a secret key to process it. The result of this computation remains encrypted in transit and in use, to be retrieved and decrypted by the data owner.

Preserving privacy with fully homomorphic encryption

Homomorphic encryption uses multiple types of encoding schemes to perform different classes of computation on encrypted data. Computations are represented as circuits (e.g., Boolean and arithmetical) and gates (e.g., addition/subtraction and multiplication/division). Some types of homomorphic encryption can evaluate multiple circuits with one type of gate, others can evaluate subsets of circuits with multiple types of gates. Fully homomorphic encryption (FHE) is the strongest version of homomorphic encryption, enabling evaluation of arbitrary circuits composed of multiple types of gates of unbounded depth.

The first plausible FHE scheme was constructed in 2009 by Craig Gentry at the IBM T.J. Watson Research Center, using a form of lattice-based cryptography that is the basis of various quantum safe cryptographic schemes. IBM has continued to research and develop FHE technology since this breakthrough, culminating in the announcement of IBM HELayers in 2021. IBM HElayers is a software development kit (SDK) for the practical and efficient execution of encrypted workloads using homomorphically encrypted data.

Protecting data confidentiality happens in three main locations:

• At rest — for example, by using symmetric encryption such as AES with Galois/Counter Mode (AES- GCM) or XEX Tweakable Block Cipher with Ciphertext Stealing (AES-XTS);
• In transit — for example, by using cryptographic protocols such as Transport Layer Security (TLS) 1.3;
• In use — for example, by using FHE.

Figure 1 — FHE operations example (Source: IBM)

The difference between homomorphic encryption (HE) and FHE is that the former supports one or two operations, while the FHE supports any number of operations.

The ISP team recognized that FHE has the potential to support a zero trust strategy by keeping clients’ digital asset transactions data, the models that process the data and the generated results encrypted end-to-end, including during computation. This advanced security approach can protect against external attacks and insider threats stealing intellectual property or sensitive information, intentionally or inadvertently. Intesa Sanpaolo monitors the progress of emerging technologies that would offer greater protection for digital asset transactions.

ISP team determined that FHE had reached a level of maturity that warranted an experiment to assess its place in their security and privacy strategy, and selected IBM HELayers because of the functional capabilities and performance.

Intesa Sanpaolo technical discovery workshop

In August 2023, the ISP Cybersecurity Lab joined IBM Client Engineering, IBM Consulting and IBM Research to participate in a technical discovery workshop based on the IBM Client Engineering Value Method. This is an Enterprise Design Thinking framework that encourages a blue-sky collaborative approach to help define a business opportunity, or to drive new insights into an existing idea. The methodology identifies and understands context, constraints and challenges, while defining the scope of a prototype solution that would be required to prove or disprove agreed hypotheses.

This gave the IBM team an opportunity to listen and learn about ISP’s goals and challenges, and for ISP and IBM to explore the application of FHE in their context and use case.

Defining the use case

The design thinking approach helped the IBM team in the early phase of the project. In a workshop, the IBM and ISP teams mapped a new user journey for the chosen use case scenario, considering ISP’s needs and requirements and using all the insights to better design the user experience, fundamental for the testing phase.

The chosen scenario was to enable a client to execute a cryptocurrency transaction with a third party. The bank would approve the transaction if the third party did not appear on its blacklist and sufficient funds existed in the client wallet. The innovation is that the details of the third party and other transaction details remained encrypted throughout the transaction. Using FHE, the encrypted third-party details were validated against the bank blacklist and approved or rejected without exposing any sensitive data to any of the parties involved, improving security and privacy for all participants.

Figure 2 — Use case scenario defined with FHE (Source: IBM)

The solution was built to show the execution of the transaction and the computation validation. There are two different applications—one for the customer and WalletWeb3—and a control console for the bank.

By using the WalletWeb3 application it is possible for a client to perform transactions on a chosen Bitcoin (BTC) address. It is a unique identifier used to receive and send BTC transactions and is a string of alphanumeric characters that is generated when a user creates a BTC wallet or generates a new receive address for their existing wallet. Each BTC address is associated with a public key, which is a mathematical function that can be used to verify the authenticity of a BTC transaction and authenticate the sender’s identity. The private key of an address is used to sign transactions and demonstrate ownership of the BTC associated with that address. BTC addresses can be used to send and receive payments, as well as to store and manage BTC funds. They are typically displayed as a QR code or a string of characters that can be scanned or manually entered by the recipient.

Once a client starts a transaction, communication with the bank is initiated and later, using a multiparty FHE method, the bank sends the response to the user without knowing the answer.

The interfaces below have been designed to better show how FHE can be implemented in a real-world scenario.

Figure 3 — User interface of the operation steps of the prototype developed

In detail, the IBM team performed two different scenarios, the first one to enable a valid transaction, so the chosen BTC address did not appear on the bank blacklist; the second one to show a rejected transaction, in this case the BTC address was on the bank blacklist so the transaction was rejected. To better prove this scenario, we used the same BTC address in each case. In the first test, the address was not part of the blacklist, and for the second attempt, the same BTC address was added to the blacklist by using the bank application feature as would be common in day-to-day operations.

Figure 4 — User interface of the transaction detail of the prototype developed (Source: IBM)

The results

With end-to-end processing of transactions in less than 22 seconds and a blacklist of 32,000 records, the project conclusively proved that FHE is appropriate for securing digital transactions. The benchmark results show that the compute time and the used memory size increase linearly with the number of records in the blacklist and utilizing GPU can improve the results 10x.

Results achieved by IBM Research using HElayers and the HEaaN Library from Cryptolab on a Red Hat OpenShift cluster using IBM Cloud object storage.

What the future of FHE holds

This engagement is a continuous journey to jointly evaluate the application of this technology to further possible privacy-preserving use cases that have been proposed, such as:

• Anti-money laundering and KYC
• Private transaction processing
• Compliance and risk management
• Biometric authentication and credential management

Find more information on IBM Client Engineering here, on Fully Homomorphic Encryption here, and on IBM HELayers here.