In a retail financial services environment, the compromise of a symmetric cryptographic key is a critical security breach. Such a situation is described by the ANSI X9.24-1-2017 standard. Here, we summarize the ANSI guidance on how to respond if a potential compromise has been identified.

The PCI Council requires most actors of payment networks to implement ANSI X9.24/TR-31-compliant key blocks to wrap and securely transmit, transfer, or translate key or PIN codes.

This article briefly summarizes the symmetric cryptographic key utilization and storage requirements as described by the ANSI X9.24-1-2017 (part 1) standard.

IBM’s mainframe computers have been a rock-steady part of banks’ security infrastructure for many years. Originating from the local data-center concept, the current release is able to stretch banks’ security architecture across the hybrid cloud, harnessing advantages of on-premise and cloud-native software deployments - all without compromising data security and privacy.

The IBM Common Cryptographic Architecture (CCA) is a cryptographic platform providing several functions of special interest for securing financial transactions.

In the last couple of months, facts regarding breaches that occurred during December 2018 at PostBank, the national postal bank operator of South Africa, have become known. This information is quite serious as it relates to a fraud that cost the bank millions of dollars and significantly damaged its reputation.

Invented by Mohamed Atalla, the Atalla key block is the root of all key blocks. All over the globe, hundreds of millions of financial transactions are secured daily using hardware security modules (HSMs) and the Atalla key block format that follows TR-31 guidelines. Here we will explain a bit about AKB and why a banking-grade key management system (KMS) must support it.

In the mobile environment, source code is often distributed without enough security. Programs compiled as bytecode, such as the ones developed for Java or .NET, contain almost all the original information from the source code. Programs developed with native code, usually developed in C, Objective-C, or C++, are much more difficult to reverse. In what follows, we will look at the difference between interpreted code and native code in mobile operating systems and why we still need native code obfuscation.

When developing an application for mobile banking, application hardening using code obfuscation is one possible way of protecting sensitive data. However, this may not be an acceptable solution in many different scenarios: when the data to protect must be (partially) displayed, linked to other accounts or other data, or sent to a remote network, etc. The general solution to this problem is data obfuscation.