Cryptographic and Key Management Procedure

V3.0

This document is the exclusive property of CSC Group (“CSC”) and the information included herein is considered confidential to CSC
and cannot be copied, reproduced or shared without the prior written consent of CSC.
 Cryptographic key management (BD-V3.0)

I. Purpose

Although the files exchanged between CSC and banks occur over protected VPN tunnel using
Secure File Transfer Protocol (SFTP), these measures only protect the file in-transit. The purpose
of this procedure is to protect at rest, files that contain information of sensitive nature.

II. Scope

The scope of this procedure will include primarily, all files that are exchanged between CSC and
banks over SFTP to be processed by EDP department. This includes:

File Type Sensitive Fields

Batch Input Issuer Card number, Bank Account
Application Loading Last Name, First Name, Tel Private, Card
Number (optional)
Card Status File Card Number, Expiry Date
Online Account File Card Number, Bank account
Balance File Card Number
Address File Mobile Number, Email
Response file Card Number, Bank account
Transaction File Card Number, Account Number
Minimum Due File Account Number
Link Amendment File Group Number, Client Number

In addition, the procedure will cover new files that might be introduced in the future to address
banks’ needs. CSCBank will only process encrypted files on its card management system.

III. Encryption Algorithm

CSCBank will ensure that its encryption solution is always in line with current strong cryptography
standards. The security of the cryptosystem shall depend solely on the secrecy of the key and the
initialization vector even if everything else about the system is open to public knowledge. As such,
CSC will use private key and initialization vector pairs for each bank it exchanges files with. The
selected encryption algorithm specifications are:
 Encryption Type: Symmetric
 Algorithm: Advanced Encryption Standard
 Key Sized: 256-bits
 Mode of Operation: Cipher Block Chaining (CBC)

IV. Preparation and Testing

In order to ensure that further encryption/decryption mechanisms are possible between CSC and
the bank, CSC has provided the following test key and initialization vector, along with 2 test files
(plaintext.txt and ciphertext.txt) for the bank to test its internal implementation. The below Key
and IV shall only be used for testing purposes:

 TEST KEY:
0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF
 TEST IV:

Last Review: 04/2021 CSC Private and Confidential 2

 Cryptographic key management (BD-V3.0)

ABCDEF0123456789ABCDEF0123456789
 File 1: plaintext.txt

plaintext.txt

 File 2: ciphertext.txt

ciphertext.txt

The suggested test scenarios are as follow:

 The plain text file (plaintext.txt) must be encrypted using the KEY and IV provided using
AES-256 in CBC mode. After encrypting this file, you must send the output to CSC in order
to decrypt at CSC’s end and ensure the decryption is readable.
 The encrypted file (ciphertext.txt) must be decrypted using the same KEY and IV. The clear
text shall read the same content of File 1.
These tests will ensure that encryption and decryption methods implemented by the bank are in
synchronization with CSC’s implementation.

V. Integration

CSC will integrate the encryption and decryption modules on:

 All applications that automatically upload files to SFTP
 All applications that download and process files from SFTP
CSC also recommends the Bank to automate the process at the Bank’s side for effectiveness and
efficiency.

VI. TESTING WITH OPENSSL

openssl enc -aes-256-cbc -nosalt -in C:\Users\rrifaat\Desktop\plaintext.TXT -out

C:\Users\rrifaat\Desktop\ciphertext.txt -K
0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF -iv
ABCDEF0123456789ABCDEF0123456789

openssl enc -aes-256-cbc -d -nosalt -in C:\Users\rrifaat\Desktop\ciphertext.TXT -out

C:\Users\rrifaat\Desktop\plaintext.txt -K
0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF -iv
ABCDEF0123456789ABCDEF0123456789

Last Review: 04/2021 CSC Private and Confidential 3

 Cryptographic key management (BD-V3.0)

VII. Sample Source Code

using System.IO;
using System.Security.Cryptography;

public bool EncryptFile(string sInFileName, string sKey, string sIV)

{

FileStream fsInput = new FileStream(sInFileName, FileMode.Open, FileAccess.Read);

FileStream fsEncrypted = new FileStream(sInFileName + ".tmp", FileMode.Create, FileAccess.Write);
try
{
byte[] eKey;
byte[] eIV;
eKey = StringToByteArray(sKey);
eIV = StringToByteArray(sIV);

AesManaged aes = new AesManaged();

aes.Key = eKey;
aes.IV = eIV;
aes.Mode = CipherMode.CBC;

CryptoStream cs = new CryptoStream(fsEncrypted, aes.CreateEncryptor(aes.Key, aes.IV), CryptoStreamMode.Write);

byte[] file = File.ReadAllBytes(sInFileName);

cs.Write(file, 0, file.Length);

cs.FlushFinalBlock();

fsEncrypted.Flush();

Last Review: 04/2021 CSC Private and Confidential 4

 Cryptographic key management (BD-V3.0)

fsEncrypted.Close();
fsInput.Close();
fsInput.Dispose();
//File.Delete(sInFileName);
//added .enc by ramzi instead of statement above
File.Move(sInFileName + ".tmp", sInFileName + ".enc");
return true;
}
catch (Exception ex)
{
if (File.Exists(sInFileName + ".tmp"))
{
fsEncrypted.Close();
fsInput.Close();
File.Delete(sInFileName + ".tmp");
}
else
{
fsEncrypted.Close();
fsInput.Close();
}
return false;
}
}

public bool DecryptFile(string sInFileName, string sKey, string sIV)

{
FileStream fsInput = new FileStream(sInFileName, FileMode.Open, FileAccess.Read);
FileStream fsDecrypted = new FileStream(sInFileName + ".tmp", FileMode.Create, FileAccess.Write);

try

Last Review: 04/2021 CSC Private and Confidential 5

 Cryptographic key management (BD-V3.0)

{
byte[] dKey;
byte[] dIV;

dKey = StringToByteArray(sKey);
dIV = StringToByteArray(sIV);

AesManaged aes = new AesManaged();

aes.Key = dKey;
aes.IV = dIV;
aes.Mode = CipherMode.CBC;

CryptoStream cs = new CryptoStream(fsDecrypted, aes.CreateDecryptor(aes.Key, aes.IV), CryptoStreamMode.Write);

byte[] file = File.ReadAllBytes(sInFileName);

cs.Write(file, 0, file.Length);

cs.FlushFinalBlock();
fsDecrypted.Flush();
fsDecrypted.Close();
fsInput.Close();
fsInput.Dispose();
//File.Delete(sInFileName);
//added .dec by ramzi instead of statement above
File.Move(sInFileName + ".tmp", sInFileName + ".dec");

return true;
}
catch (Exception ex)
{
if (File.Exists(sInFileName + ".tmp"))
{

Last Review: 04/2021 CSC Private and Confidential 6

 Cryptographic key management (BD-V3.0)

fsDecrypted.Close();
fsInput.Close();
File.Delete(sInFileName + ".tmp");
}
else
{
fsDecrypted.Close();
fsInput.Close();
}
return false;
}

}
public static byte[] StringToByteArray(string hex)
{
return Enumerable.Range(0, hex.Length)
.Where(x => x % 2 == 0)
.Select(x => Convert.ToByte(hex.Substring(x, 2), 16))
.ToArray();
}

Last Review: 04/2021 CSC Private and Confidential 7

 Cryptographic key management (BD-V3.0)

VIII. BI (Batch Issuer)/BA (Batch Acquirer) File Integrity

To maintain the integrity of BI files exchanged between CSC and its client banks, CSC supports the
use of hash for satisfying this purpose. Generation of the hash file should be done before
encryption, to ensure the integrity of the original file to be processed by CSC.

Hash Algorithms

Bankworks supports using the below hash algorithms:

 MD5  SHA-1  SHA-256
 SHA-384  SHA-512 

Salting the Hash

Since the Hash algorithms mentioned above are open-source and available to the public, an
optional Salt value can be used to add another level of security. A Salt is a value that will be shared
between CSC and its client bank which will be appended to the file exchanged before applying the
hash function on it. The Salt should be added as a suffix to the file before applying the hash
algorithm. This value should be kept secret or else it will fail to service its sole purpose. This
method will prevent unauthorized changes to the exchanged files.

Generating the Salt

In case a Salt shall be used, CSC will generate the Salt value and share it with a custodian assigned
by the client bank which will be responsible to save it secretly for subsequent uses. CSC
recommends that the client bank develop tools that will automatically append the Salt (which
should be stored secretly) to the file exchanged and apply the hash algorithm afterwards to obtain
a Salted Hash.

Hash File Format

The resulting hash (whether salted or not) value should be stored in a text file which will be
referred to as hash file which follow the format: <FN>.<EXT>.<ALG>
 <FN> stands for the exchanged filename, and
 <EXT> stands for exchanged file extension, and
 <ALG> stands for the algorithm being used (MD5. SHA, SHA-256, SHA-384 or SHA-512)

After generating the hash file in the above name format, both the original file and the hash file
should be uploaded to the directory “To CSC”

Verifying the Integrity

From its side, CSC will load the original file, add the secret Salt (in case a salt was used), generate
the hash and compare it to the hash value found in the hash file received from the client bank. In
case of a match, the file is genuine and will be processed. Otherwise, the file will fail to process as
this indicates that a manipulation has occurred in the file data. In this case, CSC will follow up with
the client bank for further investigations.

Last Review: 04/2021 CSC Private and Confidential 8

 Cryptographic key management (BD-V3.0)

IX. Key Management Procedure

A. Selection

CSC will generate live keys and initialization vectors in form of 2 components each, using CSC’s
key management policy and procedure. The procedures will ensure randomness and security of
the process. To generate the Key and IV, each custodian must run the commands:
 >set openssl_conf=.\openssl.cfg
 >openssl rand -hex 16
 >openssl rand -hex 8

B. Exchange

The bank will assign 2 key custodians and share the contact details with CSC. CSC designated
custodians will send each component to the bank counterparty using two different channels.
Contact details will include:
 Full Name
 Email Address
 Mobile Number
 Work Number
 Work Address

C. Storage

CSC will use key encryption keys (KEK) to protect the original keys used for file cryptography. It is
also the bank’s responsibility from the other side to implement controls that will prevent
compromise of key by unauthorized personnel.

D. Key compromise

In case of key compromise, the affected party shall notify the other party directly in order to
revoke the current keys and initialization vector and generate new key pair.

E. Crypto period

Even if the keys are not compromised, it is a best practice to periodically change the keys. The
crypto period of the KEY/IV will be defined to at least every 2 years.

Last Review: 04/2021 CSC Private and Confidential 9