Information Technology Department
Policy Document
Key Management & Card Data Encryption Policy
Document Summary
Item Value
Organization Information Dynamics
Document Name Key Management & Card Data Encryption Policy
Classification
Internal
Compliance Reference To:
Document Revision History
Date Version Prepared By
01 November 2017 1.0 Information Dynamics
21
st
January 2019 1.1 Information Dynamics
12
th
April 2020 1.2 Information Dynamics
12
th
April 2021 1.3 Information Dynamics
Document Review History
Reviewed By Version Date Signature
Janaki 1.0 30
th
October 2017
Janaki 1.1 25
th
October 2018
Minidurai
1.2 12
th
April 2020
Minidurai
1.3 12
th
April 2021
Key Management & Card Data Encryption PolicyPage 1
Information Technology Department
Policy Document
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 & Card Data Encryption PolicyPage 2
Information Technology Department
Policy Document
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.
Key Management & Card Data Encryption PolicyPage 3
Information Technology Department
Policy Document
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)
Key Management & Card Data Encryption PolicyPage 4
Information Technology Department
Policy Document
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
Key Management & Card Data Encryption PolicyPage 5
Information Technology Department
Policy Document
Automatic Key Rotation – Enabled
Key Management & Card Data Encryption PolicyPage 6
Information Technology Department
Policy Document
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 ;
Key Management & Card Data Encryption PolicyPage 7
Information Technology Department
Policy Document
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.
Key Management & Card Data Encryption PolicyPage 8
Information Technology Department
Policy Document
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:
Key Management & Card Data Encryption PolicyPage 9