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.

In the mobile environment, while debuggers are legal and legitimate development tools, they can also be used to reverse mobile banking and payment applications. This article describes some of the possible anti-debug techniques.

Here we describe some of the HTTPS vulnerabilities in the context of mobile banking and their countermeasures.