You are currently on IBM Systems Media’s archival website. Click here to view our new website.

MAINFRAME > TRENDS > SECURITY

Tokenized Encryption: Online Interface Call Parameters

call parameters
 

In my last article I provided a high-level overview of different components or considerations—advantages, architecture, error handling, documentation and call parameters— involved in building a cryptographic interface that pass information between the cryptographic interface and application programs or users. While the interface discussed is mainframe-based and oriented to CICS Transaction Server, the principles and concepts apply to all processing platforms, though syntax, parameters and implementation specifics may vary.

A call parameter is a special kind of variable used in programs of virtually any language on any platform as a universal mechanism for passing information between programs, routines, subroutines, functions, procedures, etc., of identical or different languages. A call—sometimes known as a link, invocation, transfer of control or branch—is a mechanism for passing control between program objects. When the called object completes, control is passed back to the calling program’s next sequential instruction, with the same call parameters, some or all of which provide results as requested.

Cryptographic Interface Subsystems

The cryptographic interface has three basic components:

  1. A batch subsystem that processes records reflecting transactions like orders, payments, requests, etc., in groups (i.e., batches). The cryptographic batch subsystem has certain parameters unique to this processing mode and some common with one or both of the other subsystems. Batch will be discussed in the next article.
  2.  A system level subsystem that provides utility, administrative, diagnostic, testing or investigative functions related to cryptography. T; these functions are limited to specific individuals or groups, and and tend to be infrequently used. Their facilities are crucial components of a cryptographic interface. This will be discussed in a future article.
  3.  An online subsystem providing real-time, interactive processing where changes like order entry take effect immediately and confirmation is promptly presented to a user. Transactions are processed singly, files or databases are updated immediately and processes are set in motion to complete the unit of work. This is predominantly where credit card (CHD) and checking account (CAD) information enters the system. Consequently, this is where most tokenization and related cryptographic activity occurs and is the focus of this article.

Online Cryptographic Interface Call Parameters

Three parameters need to be passed from a calling online program to the cryptographic interface:

  1. PCI-RECORDS-TO-PROCESS: This three byte numeric field is the number of CHD and/or CAD numbers that have been placed in TN001BC-PCI-CARD-OR-TOKEN for processing. A value of one is always used for online.
  2. PCI-CARDNUM-OR-TOKEN(index): This 16 byte alphanumeric field contains CHD or CAD to be tokenized, replaced with a token number when passed back. Order number may also populate this field. A value of one is always used for online.
  3. PCI-REQUEST-MNEMONIC: This three byte alphanumeric field contains the mnemonic specifying the operation to perform. The mnemonics used are listed below.

Mnemonic Values Indicating Function to be Performed

Update Functions:

  1. TKC: Encrypts a credit card number (CC#), creating a token to represent the CC#, (and serving as a record key) adding both creation-time and last-modified-time audit information such as date, time, operator ID, transaction ID and calling program before writing it to a Token File.
  2. TOR: Performs all the functions of TKC plus it adds order number to the token record it creates and stores it in the Token File.
  3. Encrypts a concatenated value of bank routing and checking account numbers (CAD#), creating a token to represent the CAD# and then it adds both creation-time and last-modified-time audit information such as date, time, operator ID, transaction ID and calling program before storing it in the Token File.
  4. TRK: Performs all the functions of TCK plus it adds order number to the token record it creates and stores in the Token File.
  5. RCC: Changes the encrypted CC# value in an existing token record to the encrypted value of a new credit card and updates last-modified audit information such as date, time, operator ID, transaction ID and calling program before writing it to the Token File. For audit purposes, it’s a new record. The two records can be tied together via order number.
  6. RCC: Changes the encrypted CC# value in an existing token record to the encrypted value of a new credit card and updates last-modified audit information such as date, time, operator ID, transaction ID and calling program before writing it to the Token File. For audit purposes, it’s a new record. The two records can be tied together via order number.
  7. REC: Changes the CAD# to the encrypted value of a new encrypted check account number concatenated with bank routing number and updates last-modified audit information such as date, time, operator ID, transaction ID and calling program before writing it to the Token File. For audit purposes, it’s a new record. The two records can be tied together via order number.
  8. COR: Either populates or overlays order number in an existing token record. In addition to adding or changing order number, last-modified audit information such as date, time, operator ID, transaction ID and calling program before writing it to the Token File.
  9. Read-only functions:

  10. DCC: Randomly reads the Token File using the token passed in PCI-CARDNUM-OR-TOKEN by a calling or LINKing program as a key to the read operation. The encrypted CC# is then decrypted and passed back to the calling or LINKing program.
  11. DCO: Randomly reads the Token File via a secondary read operation. PCI-CARDNUM-OR-TOKEN contains an order number, not a token number. The cryptographic interface randomly reads Order File using order number as a key, extracts the token number from the order record and randomly reads the Token File using a token. The encrypted credit card number is decrypted and passed back to the calling or LINKing program.
  12. DCE: Randomly reads the Token File using the token passed in PCI-CARDNUM-OR-TOKEN by a calling or LINKing program as a key. After the record is read, the encrypted value of CAD# is decrypted and passed back to the calling or LINKing program.
  13. FSN: Randomly reads the Token File using the token passed by a calling or LINKing program as a key. After the record is read, the first six and the last four CC# digits—stored in clear text—are returned to the calling or LINKing program. No decryption is necessary.
  14. The SIX function randomly reads the Token File using the token passed by a calling or LINKing program as a key. After the record is read, the first 6 CC# digits—stored in cleartext—are returned to the calling or LINKing program. No decryption is necessary.
  15. FOR: Randomly reads the Token File using the token passed by a calling or LINKing program as a key. After the record is read, the last four CC# number digits—stored in cleartext—are returned to the calling or LINKing program. No decryption is necessary.
  16. EWT: Encrypts a credit card number for use by a batch program for file transfer or other purposes. The encrypted CC# is returned to the calling program/transaction, but not stored in the Token File. This is a safe, PCI-compliant way to pass a CC# from one program to another or another network node via file in conjunction with the Decrypt-Without-Token function.
  17. Decrypts an encrypted CC# for use by a batch program, for file transfer or other purposes. The decrypted CC# is returned to the calling program/transaction, but not stored in the Token File. This is a safe, PCI-compliant way to pass a CC# from one program or network node to another via file, in conjunction with the Encrypt-Without-Token function.
  18. The Good Guys Win

    A cryptographic interface is designed to be fed classified, confidential or sensitive data to transform it into a protected asset that can be manipulated or accessed only by authorized individuals and distributed under carefully controlled circumstances. It enables programming staffs naïve to the vagaries of security to effectively build applications through various invocation methodologies that provide strong security using simple interfaces. It also offers organizations with solutions to the dangers and risks associated with the wide accessibility of networks and the motives of ill-intentioned miscreants.

Jim Schesvold can be reached at jschesvold@mainframehelp.com.



Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.



Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Application Integration With PCI

The problematic nature of PCI-compliance application integration makes research, analysis and planning important. It can also greatly simplify and reduce the effort involved.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters