[OPENDJ-2619] Specification for attribute encryption and hashing Created:
13/Jan/16 Updated: 13/Jan/16
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Open
OpenDJ
core server, security
4.0.0
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Task
Matthew Swift
Unresolved
None
Not Specified
Epic Link:
Encrypt/Hash Sensitive Attributes
4.0.0
Priority:
Assignee:
Votes:
Major
Matthew Swift
0
Not Specified
Not Specified
Description
Requirements for both hashing and encryption:





administrators should be able to configure which attributes they want protecting and in
which entries, as well as the algorithm used for protecting the attributes. The
configuration model should handle multi-tenancy by, ideally, storing the configuration
in the user data (e.g. using LDAP sub-entries). Symmetric keys, when used, must not be
shared among tenants
administrators should be able to import LDIF content containing clear text or preencoded protected attributes
client applications should be able to perform update operations containing clear-text
attributes values and have them automatically encoded by OpenDJ. Clients may be able
to perform updates including pre-encoded attributes
client applications should be able to perform comparison operations against hashed
attributes. The assertion value will be clear-text and must match the stored hash value
client applications may be able to perform comparisons against encrypted attributes,
although the capability should be configurable.
Additional requirements for encryption:


administrators should be able to identity which privileged clients are expected to access
encrypted attributes
privileged clients should be able to request a copy of the symmetric key used for
encrypting an attribute to which they are allowed access. They should be able to do this
using an extended operation containing the ID of the symmetric key and their public key
which will be used for encrypting the symmetric key. We already use a similar operation
for key distribution among replicas using the "GetSymmetricKey" extended operation
NOTES:



do we want to support searching against hashed or encrypted attributes and, if so, do we
want the ability to index the protected attributes?
if we use sub-entries for configuration then how do we handle case where an import
LDIF includes both the sub-entries and the attributes to be protected? Presumably we
already have this problem for password policy sub-entries.
is it reasonable that replicas are considered to be privileged applications? This is already
the case for encrypted passwords. Replicas will need to decrypt symmetric keys in order
to encrypt values, distribute keys to privileged clients, and also to perform comparisons
between attribute values (e.g. checking for duplicates, add/remove modifications).
Acceptance criteria:




definition of how the feature should be configured (e.g. config vs sub-entries,
algorithms, etc)
definition of how encoded attributes will be represented in LDAP entries and, in
particular, any implications regarding schema enforcement
definition of the operations that we'll support against a protected attribute. In particular,
LDAP operations (search, compare, modify, add, etc), indexing, and import/export (preencoded values)
definition of the key distribution protocol for encrypted attributes.
Comments
Comment by Matthew Swift [ 13/Jan/16 ]
Here's a sample LDIF containing a hypothetical attribute encryption configuration sub-entry.
The sub-entry could be split in two: one for credit card + payment system and one for passport +
reservation system:
cn=sensitive attributes,ou=customers,dc=SqueezyJet,dc=com
objectClass: subentry
objectClass: encryptedAttributesSubentry
#
# determines which entries are subject to encryption
#
subtreeSpecification: { ... }
#
# the sensitive attributes which need encrypting
#
encryptAttribute: creditCardNumber
encryptAttribute: passportNumber
#
# the crypto algorithm - a separate key will be allocated for each sub-entry.
# I.e. no two sub-entries will use the same keys even if they are the same
# config.
#
encryptionAlgorithm: AES/CFB/NoPadding
encryptionKeySize: 128
#
# the clients for which we'll provided encrypted copies of the encryption key
#
privilegedClient: cn=payment system,ou=applications,dc=SqueezyJet,dc=com
privilegedClient: cn=reservation system,ou=applications,dc=SqueezyJet,dc=com
Here's a sample user entry containing the encrypted attributes. I've used an attribute "transfer"
option to indicate that the value has been encrypted:
cn=bjensen,ou=customers,dc=SqueezyJet,dc=com
objectClass: customer
...
#
# encoded as the symmetric key ID + the encrypted value. Key IDs are never
re-used.
#
creditCardNumber;encrypted: BA5E64BA5E64BA5E64BA5E64BA5E64=
passportNumber;encrypted: BA5E64BA5E64BA5E64BA5E64BA5E64=
In order to decrypt the values a privileged application must first acquire the symmetric key used
for encryption. With some minor changes we could leverage the existing GetSymmetricKey
extended operation. The client sends the request containing the key ID and its public key and
receives back the encrypted key which it then decrypts using its private key. OpenDJ will reject
the request if the client is not registered as a privileged client for the specified symmetric key.
Generated at Tue Feb 09 13:41:12 GMT 2016 using JIRA 6.3.9#6339sha1:46fa26140bf81c66e10e6f784903d4bfb1a521ae.