Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for encrypted archives #206

Open
jas88 opened this issue Jan 7, 2022 · 5 comments
Open

Support for encrypted archives #206

jas88 opened this issue Jan 7, 2022 · 5 comments
Assignees

Comments

@jas88
Copy link
Member

jas88 commented Jan 7, 2022

Supporting encrypted archives would be beneficial if possible, allowing encrypted-at-rest archival of imaging data (split out as new issue from #204)

@jas88 jas88 self-assigned this Jan 7, 2022
@tznind
Copy link
Contributor

tznind commented Jan 11, 2022

You can add the following to any module that wants to read encrypted zips (e.g. FoDicomBasedAnonymiser/ Dicom File Collection ...). Should be quite simple:

[DemandsInitialization("Password to use when unzipping archives")]
public DataAccessCredentials ZipCredentials { get; set; }

In the RDMP UI the user will see a dropdown and be able to pick/create one and it will be tied in with the rest of the RDMP encryption / password management.

@jas88
Copy link
Member Author

jas88 commented Jan 11, 2022

Sounds good for interactive use on one-off loads, how about command-line/batch? (e.g. if we have a dump of 120 from EPCC each encrypted with a different key...)

@tznind
Copy link
Contributor

tznind commented Jan 11, 2022

It persists in the RDMP database so you configure it once per load/extraction pipeline - not every time you run it. But if the archives have different keys then it is less easy. You could probably do something like have an array of them and use the usernames to distinguish which subdir of the archive each credential applies to. But that would only scale to double digits. Is there a reason to think we are getting 120 different passwords?

@jas88
Copy link
Member Author

jas88 commented Jan 11, 2022

There isn't a username, just a password- I have a feeling that's how EPCC did their 120 archives, but they may have used a single key for all of them.

My thought was to store the key in the DICOM ref (probably base64?), so a file within an encrypted zip would be something like "\fs-de-01\imaging\epcc524.7z!7477fd836ac6744!somescan164.dcm". Alternative might be trying to reuse credential handling somehow, like a dummy "user" of the archive file name?

@tznind
Copy link
Contributor

tznind commented Jan 11, 2022

something like "\fs-de-01\imaging\epcc524.7z!7477fd836ac6744!somescan164.dcm".

I don't think we want to put the password into our imaging database.

I was thinking something like this:

[DemandsInitialization("Password to use when unzipping archives")]
public DataAccessCredentials[] ZipCredentials { get; set; }

public DataAccessCredentials GetPassword(string path)
{
    // if ZipCredentials.Length == 1
           return ZipCredentials[0]

   return ZipCredentials.FirstOrDefault(c=>path.StartsWith(c.Username))
}

That lets you setup credentials
username: /nccid/
password: asdbasdd
username: /npacs/
password: dddddd

I think that might be what you were hinting at though with the dummy "user"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants