Cryptographic Key Management System Tips for the Banking Industry

This article discusses the shortcomings and learnings from penetration testing of cryptographic key management systems for banking organizations.An alarming increase in data breaches indicates that many organizations fail to implement proper security controls and policies. Banking and financial services are seen as a potential target for data hungry hackers. Cryptography ensures to provide efficient security control but it doesn’t have any value unless the keys are properly protected. Cryptographic techniques use keys that are managed and protected throughout their life cycle by a key management system. 

Why run a Key Management System security assessment for banks?

A key management system solution implemented at bank should be tested for vulnerabilities and risks, due to the highly sensitive data that banking applications deal with. It is recommended that the findings of the assessment should be first addressed before initial deployment of the key management system. Penetration testing is a sub-category of security assessment, which includes experts developing penetration scenarios for the system as a whole and then evaluates the risk of a successful attack.

Since key management is the hardest part of cryptography, penetration testing and auditing of crypto systems in banks are vital for successful operation. The scope of penetration testing should include personnel, facilities, and procedures.

1. Documentation of a Key Management System

Most of the security controls employed by Internet banking applications are dependent on cryptography, and therefore also dependent on secret keys. A key management system Security Policy should be written so that the people responsible for maintaining the policy can easily understand the policy and correctly perform their roles and responsibilities.

Policies specified in a formal language should be automatically enforced by a key management system designed to do so. Such systems may be able to check themselves for proper function-ing, diagnose current or potential problems, report the problem to the responsible organizational entity, and perhaps even automatically correct the problem.

2. Malware Protection

Key management system devices or servers that receive communication data, files and other information over unprotected networks should scan the information for malware. Malware protection may be less critical if no information is received over unprotected networks, or if all information is strongly encrypted. Regular automated scans can detect viruses and malware in the system. Malware protection includes usage of Anti-spyware and Rootkit detection and prevention.

3. Server and Device Hardening

• Removing all non-essential software programs and disabling unnecessary network ports
• Using the principle of least privilege to control access to sensitive system information
• Running the applications with the principle of least privilege
• Disabling removable media
• Key management system device-level event logging in order to support personal accountability and to investigate anomalies, and user account management for the key management system

4. Third-party Testing

Performing third-party tests of a key management system device for conformance to a particular standard. Third-party testing provides confidence that the vendor did not overlook some flaw in its own testing procedures. This is because, a third-party penetration testing simply answers the question: “Can someone break-into the system and what can they attain?”.

5. Ease of Use

User interfaces that adapt to the expertise of the user can guide a new and less-trained user, while permitting an expert to use efficient short cuts and to bypass step-by-step guidance. Possibly the most significant constraint to the use of a key management system is the difficulty that some systems present to the untrained users. Since most users are not cryptographic security experts, and security is often a secondary goal for them, the key management system needs to be as transparent as possible.

6. Remote Monitoring

A key management system should audit security-relevant events by detecting and recording the event, the date and time of the event, and the identity or role of the entity initiating the event. Auditing the cryptographic key lifecycle to identify the state transitions of the key. Remote monitoring tools can detect modifications to system files or their access control attributes and post alerts and audit events.

7. Defining Appropriate Crypto-periods for Keys

The period of time between activation and deactivation is generally considered the crypto-period of a key. This time usually has a maximum value based on the sensitivity levels of the data it is protecting as defined in the key management system security policy.

A key management system should limit the exposure of undetected key compromises by establishing a crypto-period or usage limit for each key that it uses. At the end of each crypto-period, a new key could be established to replace the old key. In determining the crypto-period for master keys, the procedural risks surrounding over-frequent initializations should also be considered, against infrequently invoked, perhaps forgotten, procedures.

8. Assigning Key Management System Roles and Responsibilities

Banking organizations do have key management system solutions in place, but some fail to assign proper roles and responsibilities. Each role should have specific authorizations defined for it, and the persons performing that role should be provided access to a set of key and metadata management functions that are necessary for carrying out the responsibilities of the role. A few of the key management system roles include: System Authority, System Administrator, Cryptographic Officer, Domain Authority, Key Owner, Key Custodian, Audit Administrator, etc.

9. Meeting the Organization’s Information Security Policies

An organization may have different policies covering different applications or categories of information. Key management system security policies must be defined based on the information security policy of the bank. This includes use and protection of cryptographic keys, algorithms and key metadata.

In other words, the key management system security policy must specify rules for Confidentiality, Integrity and Availability (CIA) of all authentication keys and metadata used by the Key Management System.

10. Defining and Classifying Cryptographic Zones

In banking applications, sensitive data includes account number, PIN, password and transaction details. These data are encrypted at rest and transit. A cryptographic zone exists between two points, where a symmetric key or asymmetric public keys are shared in order to encrypt sensitive information. Once the key, or keys have been exchanged, data, and in some cases other keys, are encrypted within this zone.

These zones are classified into 3 parts:

1. Zone 1: External User and Banking App

When the user connects to the secure (https) Internet Banking web site, the browser establishes an SSL or TLS session

2. Zone 2: Web server and App Server:

Many banking applications send this data in clear text, but if a hacker is able to compromise the web server, he would have similar rights to view credentials in the clear. Therefore, it is highly recommended to send the data through a new encrypted session by either establishing a new SSL session, or transferring data through an IPSec tunnel.

3. Zone 3: Application server and Database Server

On receipt of the sensitive data, the Application Server needs to send it to the database server for verification. Ideally, these data elements are then encrypted with a symmetric key which has been pre-negotiated with the mainframe system.

Conclusion

Key management system penetration testing for banking organization is used for enhancing the security of the system and the key management system should be properly upgraded, reviewed and tested post closure of the penetration test findings.

References

European Payments Council: GUIDELINES ON ALGORITHMS USAGE AND KEY MANAGEMENT

E. Barker, M.Smid, D. Branstad, S. Chokhani: NIST Special Publication 800-130 - A Framework for Designing Cryptographic Key Management Systems

E. Parkin: Cryptographic Key Management Principles applied in South African Internet Banking