[
https://issues.apache.org/jira/browse/RANGER-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17893910#comment-17893910
]
Vikas Kumar commented on RANGER-3174:
-------------------------------------
*Approach:*
If FIPS flag enabled and latest algo configured inside *dbks-site.xml*
* Then, programatically adding BouncyCastleProvider as security/crypto
provider. Dependencies for this jar is already present, so no new dependecies
introduced.
* Then, it decrypts the Masterkey using older algo and re-encrypts it using
the latest one. This way, MK key material remains same but it gets encrypted
with the new algo. MK format in DB contains the algo name, so it becomes easy
to decide which algo to use to decrypt the material.
* For zone keys, One new key attribute is introduced that keep the name of
algo used to encrypt the key material. If not re-encrypted, it remains empty.
If FIPS flag is not enabled, there will not be any impact and it should work as
older.
Please note that I have not added BouncyCastleFipsProvider ( from bc-fips jar)
as it was contradicting with bc-prov jar (already present in KMS) that is being
used for some HSM client. But we are using the same algo from bc-prov jar.
Anyways, bc-prov is the superset of bc-fips.
To use bc-fips jars, users may configure _BouncyCastleFipsProvider_ in the
JRE's java.security file.
Note: To minimise the impact, I am keeping this only if
r{_}anger.keystore.file.type=bcfks{_} or {_}default keystore is bcfks{_}.
*Testing:*
*Strategy:*
- Generate one EDEK,
- decrypt it to get DEK and save the DEK material.
- After patch, decrypt the same EDEK and verify the DEK material.
- Expectation is that it must remain same and if DEK content is same, then the
files encrypted with older key will remain accessible after key re-encryption.
*Test executions:*
Old test cluster (without this change)
*Step1:* Created one EDEK
{code:java}
Reqest: curl -ivk -H "Content-Type: application/json" -H -X POST
'http://apacheprtest.site:9292/kms/v1/key/pbealgotest/_eek?eek_op=generate&num_keys=1&user.name=keyadmin'
Response:
{
"encryptedKeyVersion" : {
"material" : "G90ZtTKOWIICXG_wpqx0tA",
"name" : "pbealgotest",
"versionName" : "EEK"
},
"versionName" : "pbealgotest@0",
"iv" : "6-ZA5dd7a-TWuee3coFzWg"
}
{code}
*Step2:* Decrypted the EDEK
{code:java}
Request: curl -ivk -H "Content-Type: application/json" -H -X POST --data
'{"name":"pbealgotest","iv":"6-ZA5dd7a-TWuee3coFzWg","material":"G90ZtTKOWIICXG_wpqx0tA"}'
'http://apacheprtest.site:9292/kms/v1/keyversion/pbealgotest@0/_eek?eek_op=decrypt&user.name=keyadmin'
Response:
{
"material" : "7l07elmiCGbeCx2OgCH2Rg",
"name" : "pbealgotest",
"versionName" : "EK"
}
{code}
*Step3:*
Patch the cluster with current changes
Update the value of
"ranger.kms.service.masterkey.password.encryption.algorithm" property inside
dbks-site.xml from PBEWithMD5AndDES to PBKDF2WithHmacSHA256
Manually mark the fips flag enabled ( in code for testing)
Restart the cluster
*Step4:* Here expectation was as follows:
- MasterKey should get re-encrypted with latest algo, that is,
PBKDF2WithHmacSHA256
- All zone keys should get re-encrypted with PBKDF2WithHmacSHA256
Manually checked the DB changes that shows following for the MasterKey:
{code:java}
AES,256,8,PBEWithMD5AndDES,SHA,1000,abcdefghijklmnopqrstuvwxyz01234567890,x/H7cBXW6s+nHrh8IcoQ018wwCc2xXmWbTxHGqxZnNOlfGc1Y8KxJg=={code}
And similarly, zone keys starts containing one attribute that indicates ( new
attribute introduced)the algo used to encrypt the key material. It will remain
empty if not re-encrypted. Something like following:
{code:java}
{"key.acl.name":"pbealgotest","abc":"123","keyEncrAlgoName":"PBKDF2WithHmacSHA256"}
{code}
*Step5:* To further verify the if existing keys are getting decrypted
correctly. I hit the decrypt API again and got the same response. I mean, same
DEK material.
Response:
{
"material" : "7l07elmiCGbeCx2OgCH2Rg",
"name" : "pbealgotest",
"versionName" : "EK"
}
I also verified other APIs like getMetadata, getkey, deletekey etc.
Note: I tested this logic on our internal cluster where it was integrated with
HDFS and verified that files inside encryption zone were readable after
corresponding zone key re-encryption.
Review: [https://reviews.apache.org/r/75248/]
> Weak Cryptographic Algorithm and hash function used for PBE encryption
> ----------------------------------------------------------------------
>
> Key: RANGER-3174
> URL: https://issues.apache.org/jira/browse/RANGER-3174
> Project: Ranger
> Issue Type: Improvement
> Components: kms
> Reporter: Vicky Zhang
> Assignee: Vikas Kumar
> Priority: Major
>
> PBEWithMD5AndTripleDES is used in the file
> /kms/src/main/java/org/apache/hadoop/crypto/key/RangerKeyStore.java line 310
> *Security impact*:
> MD5 is a deprecated hash algorithm and DES also not recommend for symmetric
> encryption. The use of a broken or risky cryptographic algorithm is an
> unnecessary risk that may result in the exposure of sensitive information.
> Useful resources: [https://cwe.mitre.org/data/definitions/327.html]
> *suggestions*:
> According to the
> [https://tools.ietf.org/html/rfc2898.|https://tools.ietf.org/html/rfc2898,]
> PBKDF2 is highly recommended while doing PBE encryption
> *Please share with us your opinions/comments if there is any:*
> Is the bug report helpful?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
