Confidential fields

Implementation - Implémentation
,
1

Hi, am using docker and the Sierra Leon test database version 2.40.4.1 and postgis 13.
After trying to set an existing attribute as confidential and getting this error:

“Confidentiality option not available since encryption is not configured”

TEST 1:
I went into dhis.conf I added the following lines:

encryption.password = mylongencryptionpassword123

After restating, I get the same error. Dhis.log, has nothing.

TEST 2:
I went into dhis.conf I added the following lines:

encryption.password = myshortpassword

After restating, I get the same error. I get a Warning on dhis.log, that says that my encryption password is too short - which is expected as per the docs. This indicates that the variable is indeed being read.

TEST 3:
I went into dhis.conf I added the following lines -including a password that is over 24 chars long:

encryption.password = mylongencryptionpassword123
logging.level.org.hisp.dhis = DEBUG
logging.level.org.jasypt.encryption = DEBUG

After restarting, clearing cache, I went back to confidentially option and still got the same error message saying that is not configured. The same error is also displayed when trying to add a new TEA.
dhis.log only shows the lines below, no mention of encryption, and no errors are logged.

  • INFO 2024-07-19T17:31:10,675 Added logger: org.jasypt.encryption using level: DEBUG (Log4JLogConfigInitializer.java [main])
  • INFO 2024-07-19T17:31:10,675 Added logger: org.hisp.dhis using level: DEBUG (Log4JLogConfigInitializer.java [main])

Any ideas of what am missing or how else to debug this error?
thank you!

1 Like
2

Hi

I’m assuming the actual password follows the docs instructions " The password must be at least 24 characters long . A mix of numbers and lower- and uppercase letters is recommended."

Note: I also tried to activate encryption on a docker instance and modified the dhis.conf file, but I’m getting the same issue as you are… I will ask other team members, thanks!

2 Likes
3

Hi again,
I finally had time to take a closer look at what is happening and here is what I found.

The log does show this message " Encryption is available (ConfigurationPopulator.java [main])".
However, when creating a new TEA the Confidential option still says that encryption is not available. Encryption is probably not available for attributes that already contain data, but it seems to be disabled for both new and existing attributes.

The only way that encryption seems to be available on the web interface is when you start with a clean installation.

So I started with a clean installation and imported the metadata from the Sierra Leone demo installation. Before importing TEIs, I changed the “name” and “last name” attributes to confidential. After completing the import of the instances, I looked into the database and to my surprise values for confidential attributes are saved in both plain text and encrypted fields (see image below).

Now I am trying to understand the goal of this feature, I thought it was to encrypt data at rest but I see that is still visible on the database.

ecryptedvalues

2 Likes
4

Hi @Eric_Boyd_Ramirez

Very good points you mention here, thanks for the update.

Interesting! I’m asking the team about this. Thanks! :slight_smile:

5

Dear DHIS2 Community,

I have enabled encryption in DHIS2 and marked two attributes in a tracker form as confidential. I expected these values to be stored only in an encrypted format, but they are also being stored in plain text.

image

Has anyone else encountered this issue or have any insights on what might be causing it? Any suggestions or advice would be greatly appreciated.

Thank you!

6

Hi @Eric_Boyd_Ramirez and @sami12111

There are currently more advanced encryption tools than this feature. Previously, this old feature seems to have been used to ‘hide’ data from non-privileged users; however, I’m not sure what is the status quo for this feature and whether it’s going to be continued or not since there are other alternative options.

I’ll see if I could get an expert response from @dhis2-security . Thank you! :pray:

7

@sami12111 Can you describe your primary use case for encryption? Who should not be able to see the encrypted data? Having more context here will help us to provide better advice.

1 Like
8

Hi @mmarkevich and @Gassim

We want to encrypt all the Personally Identifiable Information (PII) in the forms and only the superuser or system administrator should be able to access it.

@Gassim could you please share advanced tools and alternative solutions for this use case?

Thank you.

1 Like
9

@Gassim, if this is how the feature is supposed to work, I think the documentation should be updated to say that enabling and using Confidential attributes creates an encrypted copy of the attribute value in the database and keeps the unencrypted value as well.

@mmarkevich, just as @sami12111 mentions, with countries putting in place their data protection regulations, there’s more demand for ensuring Personally Identifiable Information is encrypted at rest. We already encrypt the hard drive, but that doesn’t prevent anyone authorized to run SQL queries from seen people’s PII. The same goes for DB backup copies, but one can encrypt those.

There are a number of techniques and Postgres tools that could be used to encrypt PII, the challenge is to ensure that it doesn’t break DHIS2. And so, ideally this would be tested/included as part of the DHIS2 package.

2 Likes
10

@Eric_Boyd_Ramirez, thank you for the explanation! It was super-helpful. Now we’ll take a round with the security team to discuss the case and what we can offer.

1 Like
11

Hi @mmarkevich,
I hope you are doing well. Just wanted to check if there has been any developments from the security team on this, or any new features that we can contribute to.
Thank you!

1 Like