Staying Aware of Security Mandates and TG-3 Compliance

Today customers are increasingly aware of the importance of security policies.

This is why differentiating your company with better overall policies and procedures can be a silver lining around what some regard as the black cloud of a regulated environment.

Understanding and complying with the industry standard security compliance is the core focus for Information Security departments across the financial enterprise. Over the past 7 years the security requirements have changed and networks require compliance in order to process transactions.

Do you comply with TG-3 Requirements?

In order to comply with TG-3 standards it is important to know what they are.

TG-3, or Teaching Guide 3, is the ANSI checklist for auditing the security of online PIN and key management in accordance with the ANSI 9.24 part 1 standard. Today just about everybody who works with electronic financial transactions should be familiar with the TG-3 requirements. However, now, ANSI is releasing 9.24 part 2, which covers asymmetric (Public) keys as well as symmetric (TDES) keys for PIN and key management use. Along with 9.24 part 2 comes a revised TG-3 to cover all of the new requirements.

As the committee continues to grow the mandates and requirements are becoming more and more specific as it pertains to encryption and hardware devices.

With respect to the original TG-3 requirements for the encryption and hardware (TRSM/HSM) the mandates are:

• Any authorized or unauthorized physical or functional modification of cryptographic equipment that could result in the disclosure of cleartext PINs, keys, or other sensitive data:
• is not feasibly possible, or
• has a high probability of causing the erasure of all cryptographic keys contained within the equipment, or causes the detection of the modification, or prevents subsequent operational use of the modified equipment.
• Typically, devices validated under FIPS 140 (-1 or -2) at level 3 met these requirements, and are the most commonly used TRSMs
• The TRSM must be protected from unauthorized access, both physical and logical
• All key entry must be performed using multiple key parts and device management must be under dual control
• Keys should only exist in a TRSM, as a cryptogram, or as two or more key parts under dual control or split knowledge.

There are, of course, many additional requirements for policy, procedure and handling of keying material, but these are the most critical ones relating to the TRSM.

Today TG-3 Announces NEW Requirements

In the new, revised TG-3, the requirements have been significantly expanded; with both specific requirements as to key size and use, and relating to the key type (symmetrical or asymmetrical).

TDEA (TDES, Triple Des, 3DES), using a double length (112bit) key is now required for PIN block encryption for transmission or storage outside a TRSM

For devices that use asymmetric techniques for the management of symmetric keys, mechanisms exist and are used that ensure mutual authentication of the sender and receiver of the keys. This means that TLS or another two authentication scheme will be needed for key delivery

• Each device and each communicating party must have a unique key
• All cryptograms must be created in a TRSM using TDES.
• Key loading requirements have been strengthened. Using the PC keyboard is not considered optimal and the cable will need to be inspected to assure that there are no snooping devices in-line. A keyloader that is a separate, single purpose device; that is also a TRSM is preferred.
• Access and changes to keys including: creation; signature generation; installation as a trusted key; storage; back up; archive; and destruction. must be logged throughout the key lifecycle
• Public key algorithms must be ANSI X9 approved, must be used in approved ways, key must be generated in approved ways and public keys must be verified in approved ways before use.

Just as symmetrical keys asymmetrical keys should only exist in a TRSM, as a cryptogram, or as fragments (key shares) using a key fragmentation algorithm such as Blum Shamir.

• Public keys may only exist in the following forms: in a public key certificate; in any form that a private key can exist (see above); or protected by a MAC
• For generating key pairs for use in other devices, the key only exists in the authorized key generating HSM and the device receiving the generated key; and the private key of the key pair and all related secret seed elements are deleted immediately after the transfer has been ensured; and the integrity and confidentiality of the private key is ensured
• Each pair of communicating parties must have their own key pair. Each key pair may only have one use
• Keys must be replaced at appropriate intervals
• Key lengths for symmetrical keys and asymmetrical keys much match in strength when used together
• Communications between PEDs and hosts, and hosts and HSMs, must be mutually authenticated
• In addition there are more requirements for Certificate Authorities and other specialized applications.

What we see is a significant number of new requirements, both 'upgrades' to the original requirements as the result of moving to TDES, as well as completely new requirements generated by the use of asymmetric (public) key algorithms.

The biggest work load increase will be key management. In the past it was common to use one key for many devices (and sometimes many purposes).

Now the requirements stipulate a single key per device, a single key per purpose, and each key must be replaced at intervals, and the entire life cycle of the key must be managed and documented while security and integrity are continuously maintained. This task has quickly become too large for any person to manage, and the security requirements make the use of a TRSM based automated key management system almost mandatory.

So, it's time to read up on the new requirements and to start working on a plan to reach TG-3 compliance. Good practice, careful attention to detail and a plan for key management will get you there.