Keys permissions and management
Keys in system
We have 3 application, that uses 5 keys for different purposes. We call these keys DEK - Data Encryption Key. To encrypt data is used AES/CBC with 16 bytes initialization vector. Keys are 128 bit length.
Application | Key name | Purpose | Fields in database | ||
|---|---|---|---|---|---|
Processor HUB |
| Personal data |
| ||
Acquirer Visa |
| Card number |
| ||
Acquirer Visa |
| Personal data and reports |
| ||
Acquirer MC |
| Card number |
| ||
Acquirer MC | personal-dek | Personal data and reports |
|
Keys
Encrypted DEK keys are stored in a database. To encrypt DEK keys is used KEK, stored in KMS. For encryption/decryption is used AWS KMS.
There are several DEK keys in a database for a given purpose. Keys have an indicated time in which they can be used for encryption.
KSA - description
We use a dedicated application to manage keys KSA.
Application in starting is requesting for keys pool for the indicated purpose. Key service (KSA) finds a defined number of keys, decrypts using KMS, and returns it to the application with information of pool lifetime (different from key lifetime).
The application uses a random key from a pool, and information about the used key for encryption is stored in a table next to the encrypted column in a separate column. To indicate the used key as an alias we use the fingerprint of the key. That let us have sure that we are using the correct key for decryption and that there was no mistake in the alias. (or we don't need to verify used key, then we can use UUID as key alias).
The application has a timer with checks the lifetime of the keys pool in memory, and when it's finished, requests new keys. For example, we used 3 random keys which are changed per hour, from a pool of 15 keys, which are replaced per month.
In the case of decryption when the application doesn’t have the key with was used for encryption, can requests for in from KSA and cached in memory for the indicated time, for example, 2 hours.
DEK in KSA database is encrypted by KEK (Key Encryption Key) stored in KMS. To encrypt keys we can use several keys in KMS, information with the key used to encrypt DEK is stored in KMS db. In KMS is defined aliases of KMS keys, should be randomly used, bat all key for one purpose, can not be encrypted by only one KEK.
In KSA for every purpose we have defined:
number of valid keys
size of pool returned to the application
pool lifetime returned to the application
length of validity time of newly generated keys
time for how long the application can keep the decryption key in cache
In KSA we have a service that checks if there is a defined number of keys and provides new keys when one of them expires. Service generates keys for the future, which means in now we have a pool of keys, that will be used when, currently working keys expire.
Key statuses in KSA
ENCRYPT- current used valid key for encryptionDECRYPT- key can be used only for decryption, the key after a lifetimeFUTURE- key for future use, for replacing currently used keyRECRYPT- asDECRYPTonly for decryption, but DRS should recrypt data used by this keyEXPIRED- old key that was used for encryption, but currently we don't have data encrypted in this key, data was recrypted by the new key, or data with the used key was removed from the database, but data encrypted by a key may still be in backup. The ke is automatically deleted after the rotation time of the backup.
KSA - monitoring
KSA is connected to a monitoring system, which notifies of irregularities:
the wrong pool size of current keys per application
the wrong pool size of future keys per application
problem with encryption/decryption DEK using KMS
problem with generating new keys
not removed keys in status EXPIRED, after backup rotation time
in the side of application, we need to monitor problems with replace keys pool
Backup
We need to turn on encrypted backup.
Open questions
Question | Answer | Data | |
|---|---|---|---|
1 | What will do with UNSUPPORTED key:
| ||
2 | Wehen data is encrypted? | Data access by panel and clearing(?) | |
3 | What storage we will use (DynamoDB), PostgreSQL? | ||
4 |
Data Recrypt Service (DRS)
Also, we need an application with can recrypt data, using new valid keys. Data Recrypt Service (DRS) has information of keys, that should be replaced. When some key in needs to be replaced, service in defined hours (for example at night, when the load is lower, partially recrypt data. KRS also returns information, on how many tuples are encrypted by the given key. KSA used this information to change the status of the replaced key. Information can be also used for the scale size of the current keys pool.
KMS
Open questions
Question | Answer | Data | |
|---|---|---|---|
1 | How it will be protected KEK? | there is no option to get keys from KMS | |
2 | How many keys will be store over there? | ||
3 | What will happen if KEK will be compromised? | AWS use HSM | |
4 | Do we need backup for KMS or turn on option of backup? | AWS is backuping keys in KMS | |
5 | Who will have access to private keys? | only AWS | |
6 | Who can use kesy in KMS? | ||
7 | Can we use asymetric DEK? | ||
8 | Retention of backup KSA database | ||
9 | Retention of Acquirrer and Hub database | ||
10 | Czy są gdzieś kopie kluczy KEK on-site, czy są one tylko w chmurze? | ||
11 | Co się stanie, gdy te klucze zostaną w jakiś sposób zniszczone? | ||
12 | Czy dane będą do odzyskania? |
Architecture
Option with asymmetric DEK
In the case of using asymmetric keys, in KSA database is stored encrypted by KEK (KMS) private key of DEK, and the plaintext public part of DEK. KSA provides for an application pool of public DEK. In this case, KSA doesn't need KMS to encrypt the key. When the application need to decrypt data, it needs to get the private key of DEK from KSA. KSA provides the private key with a lifetime after the application should remove the key from memory.