EKMS
来源：互联网 发布：mysql regexp使用 编辑：程序博客网 时间：2024/06/05 17:18
Glossary:
1. EKMS Overview:
EKMS is implementation of RSA and it is responsible for management of both asymmetric and symmetric keys.The EKMS key manage solution provides centralized, policy-based key management and encryption. It consists of Key manager client and key manager server.
2. High Level Overview:
Key Manager Client:
1. Represents a business application.
2. A development library that developers can integrate into a business application to obtain key retrieval and cryptographic capabilities.
3. Through this KM Client, application communicates with Key Manager Server to retrieve the key for performing Encrption/Decryption & Hashing.
Key Provider:
1. Java servlet to service Key Manager Client requests for encryption keys
2. Use a mutually - authenticated SSL connection for the exchange of inormation between the Key Manager Clients and the Key Manager Server Provider.
Datastore:
1. Stores all administrative and operative information abt cryptographic keys, Key Classes, Application Groups, Key Policies and Key manager Clients.
2. The Administration System has write access to the database.
3. The Key Provider requires read access.
Administration System:
1. Implemented as a set of JSP and servlets.
2. User end interface to manage Key Manager Server.
3. The types of operations and administrator can perform include:
* Create Application Groups and applications
* Update applications(import new application certificates)
* Create and assign Key Classes
* Generate keys
* Create Key Policies
* Add users
* Load and save Key Class definitions in a documented, XML - based configuration file.
Algorithms Used :
S.No Function Algorithm 1 Encryption AES 2 Decryption AES 3 Hashing Hmac3. EKMS Architecture Overview
PKCS#12 File
1. PKCS#12 (Personal Information Exchange Syntax Standard)
This standard specifies a portable format for storing or transporting a user's private keys, certificates, miscellaneous secrets, etc.
("This standard describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information")
2. A password - protected PKCS#12 formatted file stores the public key certificates and the private key.
3. Key Manager Client requires the certificates and private key to do the authentication to the Key Manager Server front-end web server during SSL connection establishment.
Config file
Stores Key Manager Client specific configuration parameters, like:
kms.cacheTimeToLive
kms.retries
kms.retryDelay
kms.debug
kms.memoryCache
kms.sslPKCS12File
kms.address
kms.cacheFile
kms.port
kms.sslConnectTimeout
kms.sslPKCS12Password
Memory Cache:
1. Cache those keys response from Key Manager Server in memory in the format of clear text.
2. Non -persistent. Only available for the life of the Key Manager Client.
Disk Cache:
1. Cache those keys response from Key Manager Server in memory in the format of clear text.
2. Persistent.
3. Sequence of searching keys : Memory Cache --> Disk Cache --> Key Manager Server.
KM Client:
1. KM Client performs key retrieval, encryption and decryption operations on behalf of a business application.
2. Each KMC has its own unique identity within a Key Manager implementation.
3. One KMC can act on behalf of multiple business applications.
4. For the KMS, every KMC has a single set of encryption key access right.
5. KMC start process:
1. reads and loads the config file.
2. reads all the configuration parameters inside the config file
3. use the PKCS#12 file name & password to unlock the PKCS file to find the asymmetric key pair which determines the Key Manager Client's authorization rights for encryption/decryption.
API (Process):
1. GetKey API
Retrieve keys for encryption, decrption and HMAC purpose.
Two kinds of key may be retrieved:
* Currently active key from a specified Key Class (usually used for encryption or HMAC purpose) <in KMS>
* A key with specific key identifier (usually used for decryption or verifying an HMAC purpose) <in the response block>
Retrieve Order:
1. Memory Cache
2. Disk Cache
3. KM Server
4. Memory Cache (update, adding the new reponse key into cache)
5. Disk Cache (update, adding the new reponse key into cache)
2. EncryptData API
Encrypts the supplied data using the current key from the specified Key Class.
The only encryption algorithm currently supported is AES.
1. Calling the getKey API to retrieve the specified class
2. Generated the random data to use as an Initialization Vector
3. Performs the AES encryption operation.
4. Prepends the key identifier of the encryption key to the ciphertext. (key+data)
5. Prepends the Initialization Vector to the key identifier/ciphertext data block. (vetcor+key+data)
6. Returns the Initialization Vector/key identifier/ ciphertext data block to the client application.
3. DecryptData API
Decrypts the supplied data that was previously encrypted with the EncryptData API.
1. Strips the Initialization Vector and the key identifier from the ciphertext.
2. Calls the GetKey API to retrieve the specified key.
3. Decrpts the ciphertext.
4. Returns the cleartext to the client application.
4. HMACData API
Two kinds of keys may be used for HASH:
* a key provided
* the current HMAC key retrieved from KMS
The process:
1. Calls the GetKey API to retrieve the HMAC key
2. Performs the HMAC - SHA - 256 operation to generate the HMAC
3. Prepends the HMAC key identifier to the HMAC
4. Returns the key identifier /HMAC data block to the client application
