Key Management & Card Data Encryption Policy

Document Summary

Document Revision History

Document           Review           History                      

1. Scope

   This policy document addresses Information Dynamics key management requirements and credit card data encryption.

   
   

2. Policy

   • Credit Card data whenever it occurs in conjunction with PAN must be encrypted. This is applicable to all data stored including data on database, portable digital media, backup media, in logs, and data received from or stored by wireless networks.

     
     

   • Encryption of card data will be carried out using Symmetric Key Encryption: AES 256 bits, or 3DES 128 bits with associated Key management procedures Asymmetric Key Encryption: RSA 2048 Bits, Deffie Hellman 2048 Bits, El Gamal 2048 Bits

     
     

   • The MINIMUM account information that must be rendered unreadable is the PAN.

     
     

   • Encryption Keys will be stored in a location separate from the encrypted data.

     
     

   • Cardholder data on removable media will be encrypted wherever stored.

     
     

   • Native File System disk encryption will not be used to encrypt credit card data.

     
     

   • Encryption keys used for encryption of cardholder data will be protected against both disclosure and misuse by:

     
     

     • Restricting access to keys to the fewest number of custodians necessary

     • Secure storage of keys in the fewest possible locations and forms

       
       

   • Key management processes and procedures for keys used for encryption of cardholder data will be documented and implemented for:

     
     

     • Generation of strong keys-

       
       

       Q1:- Key generation process and logic with description.

       
       

       Customer managed key is created in AWS IAM.

       
       

       Q2:- Data encryption key description

       
       

       1. Using Access Key id & secret key system connect to AWS KMS, and request placed to AWS KMS by sending (key Id + algorithm + key size). The response returns Data key.

       2. Using above Data key the sensitive plain text information encrypted using AES 256 algorithm in local system, then encoded using Base64. The result string is stored in local database.

     • Secure key distribution-

       Q1:- How the keys are distributed securely.

       
       

       AWS IAM Keys are split into two halves.

       
       

       Q2:-Handling process

       
       

       The Key id is split into two parts.

       
       

       1. One part is stored in database

          
          

       2. Second part is placed in Application properties file after encryption using PBEWithMD5AndDES algorithm. Which will get decrypted in run time by application.

       3. Above two parts and concatenated in run time.

       
       

     • Secure key storage-

       
       

       Q1:- Storage location of Key (Application path or Database)

       
       

       One part is stored in database & another part is stored in application.

       
       

       Q2:- This applies for DKEY & Y. Describe the location (exact),

       
       

       Key id Split into two parts :-

       
       

       1. One part is stored in database. KKE

          table (tbl_id_et_aws_kms_config_details) column name (akcd_key_id)

          
          

       2. Other part is stored in application properties file :- File Name:- application.properties

          Key Name:- amazon.config.key.part

          
          

       3. Using Access Key id & secret key system connect to AWS KMS, and request placed to AWS KMS by sending (key Id + algorithm + key size). The response returns Data key, which is encoded to base 64

       and stored in database:-

       table (tbl_id_et_card_details) column name (CD_ENC_CARD_KEY)

       
       

     • Periodic key changes-

       
       

       Q1:- Define the cryptoperiod of Keys.

       
       

       365 Days;

       
       

       Q2:- Screenshot from AWS; and describe

       
       

       Refer Below Link & Screen shots https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html

       
       

       Automatic Key Rotation – Description

       
       

       
       

       Automatic Key Rotation – Enabled

       
       

       
       

     • Destruction of old keys-

       Q1:- Secure Deletion method of keys.

       
       

       Auto deletion interval of 7 – 30 days.

       
       

       Q2:- DKEY are not taken care by AWS. Destruction and change mechanism we need to describe

       Yes. Data keys are generated for each encryption which gets stored in database:-

       table (tbl_id_et_card_details) column name (CD_ENC_CARD_KEY)

       
       

       Data Key along with encrypted data will get destructed automatically upon card expiry. Scheduler configured which check the expiry of card data by validating expiry month/ year and the data will get deleted from database if the card expired.

     • Split knowledge and establishment of dual control of keys (so that it requires two or three people, each knowing only their part of the key, to reconstruct the whole key-

       
       

       Q1:- Signed Key custodian forms needs to be provided for each user (template for key custodian form attached in mail).

       
       

       Already uploaded.

       
       

       DB – access to person and application side; both are key custodian

       
       

     • Prevention of unauthorized substitution of keys; key access to 2 persons; One is with DB persona and another with application team. Since this two person are key custodian ;

       
       

     • Replacement of known or suspected compromised keys-

       
       

       Q1:- Replacement procedure in case of end of cryptoperiod or key compromise.

       
       

       Auto Rotation on periodic interval (365 days). If Key compromised, the existing key will be disabled & will be scheduled for auto deletion after

       7 days. New Customer Managed Key will be generated in AWS and configured in application.

       
       

       Q2:- Add process for DKEY

       
       

       Data keys are generated for each data encryption which gets stored in database, If the data key gets compromised respective record/s to be deleted as the record contains datakey along with encrypted data.

       
       

     • Revocation of old or invalid keys (For RSA Keys only) -

Q1: process of revocation of keys.

The existing key can be disabled via aws console.

Q2: Add process for DKEY

Data keys are generated for each data encryption which gets stored

in database, If the data key gets compromised respective record/s to be deleted as the record contains datakey along with encrypted data.

• Requirement for key custodians to sign a form stating that they understand and accept their key-custodian responsibilities-

Q1: Signed Key custodian forms needs to be provided for each user (template for key custodian form attached in mail).

Already uploaded. Two names..

The Architect is the owner of this document and is responsible for ensuring that this policy document is reviewed in line with the review requirements stated above.

A current version of this document is available to all members of staff.

This policy was approved by the Architect and is issued on a version controlled basis under his/her signature

Signature: Date: