GA4GH Encrypted Format

Minutes and Actions 2021

These are the minutes for the Encrypted Format meetings, a subgroup of the GA4GH Large Scale Genomics Work Stream. For further information, please visit the GA4GH Work Stream page.

Table of Contents

Meeting Protocols

Agendas, Minutes and Actions

2021-04-06: 4th Meeting 2021

2021-03-09: Third Meeting 2021

2021-02-09: Second Meeting 2021

2021-01-12: First Meeting 2021

2021-MM-DD: Template

Previous Minutes

Meeting Protocols

• Please note that by participating in meetings, attendees agree to adhere to the GA4GH Standards of Professional Conduct.
• Meetings may be recorded for note-taking purposes. Recordings will be deleted within three months of the meeting taking place.
• Dates should be specified in the international format yyyy-mm-dd

Agendas, Minutes and Actions

2022-03-09: 3rd Meeting 2022

Chair: Alexander Senf

Attendees “Name (Affiliation)”:  Rob Davies (Sanger), Vasiliki Rahimzadeh

Meeting Notes:

• Mainly discussed crypt4gh, and where it fits in the privacy landscape.

2022-02-08: 2nd Meeting 2022

Chair: Alexander Senf

Attendees “Name (Affiliation)”:  Rob Davies (Sanger), Frédéric Haziza,Reggan Thomas(EBI)

Meeting Notes:

2022-01-11: 1st Meeting 2022

Chair: Alexander Senf

Attendees “Name (Affiliation)”:  Rob Davies (Sanger), Frédéric Haziza,Reggan Thomas(EBI)

Meeting Notes:

• Gerrit to help with test data
• Possible improvements:

• Limit amount of data that can be edited out
• Detect file rearrangements, maybe by using additional data to add a counter
• Header signatures

• Cloud security model

2021-12-14: 11th Meeting 2021

Chair: Alexander Senf

Attendees “Name (Affiliation)”:  Rob Davies (Sanger), Frédéric Haziza, Gerrit Botha

Meeting Notes:

Demo of EGA-QuickView (remote file system over SFTP, with Crypt4GH decrypting layer)

2021-11-16: 11th Meeting 2021

Chair: Alexander Senf

Attendees “Name (Affiliation)”:  Rob Davies (Sanger), Fred Haziza, Gerrit Botha

Meeting Notes:

2021-10-19: 10th Meeting 2021

Chair: Alexander Senf

Attendees “Name (Affiliation)”:  Rob Davies (Sanger)

Meeting Notes:

2021-08-24: 8th Meeting 2021

Chair: Alexander Senf

Attendees “Name (Affiliation)”:  Rob Davies (Sanger), Gerrit Botha, Vasiliki Rahimzadeh

Meeting Notes:

Action: RMD to test out Fred’s FUSE mount, and compatibility with the HTSlib plugin

2021-07-27: 7th Meeting 2021

Chair: Alexander Senf

Attendees “Name (Affiliation)”:  Alexander Senf (Congenica), Rob Davies (Sanger), Fred Haziza (CRG), Andrew Ponomarev, Gerrit Botha

Meeting Notes:

• Potential issues: Crypt4GH-htslib plugin via FUSE layer: unable to decrypt.

• The issue may be within FUSE layer; but not certain

• Andrew presented their work on using Crypt4GH in Intel SGX enclaves.

• Question on the security of the key exchange component, if an attacker watches memory during execution.
• Overview - SCONE Confidential Computing (sconedocs.github.io)

• Potential action points:

• Review key exchange security provisions
• Provide test data, plain as well as encrypted with sample keys, to enable implementation checks, debugging, load/performance testing

2021-06-29: 6th Meeting 2021

Chair: Alexander Senf

Attendees “Name (Affiliation)”:  

2021-05-04: 5th Meeting 2021

Chair: Alexander Senf

Attendees “Name (Affiliation)”:  

Meeting Transcript

Meeting Notes:

• Potential issues: encrypting file with samtools, decrypt with different tool may not work.

• There is a samtools quickcheck program, to test header, end of file

2021-04-06: 4th Meeting 2021

Chair: Alexander Senf

Attendees “Name (Affiliation)”:  Rob Davies (Sanger)

Meeting Transcript

Collect security use cases : Create Google doc

Reach out to Connect 20201 participants

• NIH volunteered Threat model
• Set up a DRS as a source for Crypt4GH data

Contact cloud providers for technical capabilities

Make sure Zoom link is correct in calendar

AS: So I guess one thing that we should start, which we haven't really done yet, is to collect use case security use cases.

RD: Yes. Yes, this whole key thing is coming up here as well, because they decided to come up with a new security policy, which says all your keys have to be stored securely. Okay, I'm not noticing the number. We have scattered around scripts. Contact databases. Oh, great. Yes.

AS:So are you going to try to? Yeah, I mean, but if you solve that, that may give us hints on to

RD: Well, yes. Let's certainly have a deadline for that.

AS:Is it just a policy that needs to be implemented over the next 20 years?

RD: Well, you know, it's probably supposed to be doing it now. But I think the people who wrote policy didn't know what was going on in the real world. So yeah, it is something we should probably get better at. And I do have the same problem again for the Coronavirus stuff. Because that's basically Yeah. Man. Yes, we have a few things where we need to access external services, and they have to have secured passwords. So currently, with my stuff, in order to do that, I have to basically type in a master passphrase to unlock them all. That's kind of inconvenient. Yeah.

AS: But that's different. So on the one hand, that's something we have to do. There's just no way around that. But on the other hand, that's only a response to some of the issues that would come up in in a security threat type scenario for the cloud. Yeah. I think we still, we still need to just write down what we expect could happen to the data. Yeah. And maybe something like that exists at Sanger already. If someone came up with that policy.

RD: It might be worth finding out. Yes.

AS:We could base it off that at least if nothing else are incorporated.

RD: I suspect there isn't. Somebody just wrote the policy. But thinking, basically, I know basically, coming up with the idea, you know, you shouldn't write down the password to your desktop or whatever on a piece of paper next to it. sort of thinking about rather than credentials for programs to access other resources?

AS: Yeah. Yeah. I wonder how Alexia is handling that as well. But yeah. Anyway, that would be one good thing to do at least start a document to basically what we did. Yeah. For the format itself just now for the cloud. So we can we can be a bit more targeted?

RD: Yes. I mean, you've come up with our threat models as well. Who do we want to protect ourselves from?

AS: Yes, exactly. That's what I mean. Yeah. We can probably start just a Google doc and collect our thoughts and then filter it down into something useful. Yeah.

RD: recommended that Yes.

AS:It's an action you can refer back to that next time. If we have done anything,

AS: So I should follow up with the people from Connect meeting as well. So we had the one volunteer from NIH to contribute that type of analysis from the NIH. Yeah. But I need to contact I reach out to them. So I can add that as an action for me as well.

AS:That's okay. thinking I'd organized again. Yeah. So from my end, it's mostly just following up on the things that we said we would do on unconnect. One, one of them is the threat model from NIH. Yep. The other one is, that's kind of exciting to me, but setting up a nurse server to serve crypto gh data. That might be an interesting use case also on how to exchange the various passwords and credentials we need.

AS: I could do it in a VM usually have at least one VM running.

RD: Please wait for the staff meeting so nosy me everyone. Yeah, now. Okay, sir. So either everybody's waiting a long time for the answer. Or

AS: It might be an action you can add as well.

RD: Yeah. Yes, check her check. calendar invite.

AS: Yeah. So that's, that's the only clip footage related things I can think of. Yeah.

RD: So I want to do a bit of tidying up on the eastern seaboard, because I think it has a habit of if you if you felt connected to it, for some reason in its agent throws his rifle out of its prime and stops working. Yeah, apart from that.

AS: On the other topic, though, so my current company, I, I work at congenita. Now, yeah, and they want to get so at least the the CIO is interested in getting more involved with J for gh. Um, so if I'm lucky, I'll get part of my page time to work on this again.

RD: But I might also be so that was one of the things we're doing is of course, genomic medicine, so Things like VCF, or we are representation seems like that might be interested. Interesting for them to join as well.

AS: Exactly, yeah. But yeah, I have to I have to talk to them a bit more about that. I think it would be really cool if there would be small things, small projects they could contribute. Currently, I feel like it's mostly just talking about what what should VCF look like, for example, or what should rather than having that in, in real world projects to contribute?

RD: Yes. VCF? Certainly, there's lots of work going on at the moment. So as enthusiasm for improving it.

AS: That's good. Um, you also need that enthusiasm to switch from UCF 4.2, to whatever you have in the end.

RD: Yeah, there is that? Yeah. I think that i think there may be enthusiasts and fans as well.

AS: Certainly, every consults on the scaling issues or make them less bad than there'll be? People gladly upgrading.

RD: It would be nice if it was possible to, like, swap out the format, but then be able to validate that whatever you were able to do with VCF, 4.2 or three. Yeah. still works exactly the same as the next version. Yeah, it would make companies at least a bit more happy to switch?

RD: I think the audio is generally making similar enough. The Yes, there, there are changes to things like structural variants, but they don't work very well, at the moment anyway. So.

AS: Yeah. But the thing is, you have so you're technically classified as a medical device, if you doing? So. you certify that it works once, but then if you swap out format version for another, you'd have to certify everything again, just using that new version. Yes. And that's a huge task. So people tend to not do it unless it's absolutely necessary.

RD: Yeah. Or you. You went for a massive pandemics come and then everybody throws the rulebook out.

2021-03-09: Third Meeting 2021

Chair: Rob Davies

Attendees “Name (Affiliation)”:  Gerrit Botha (H3Africa), Alef Janguas (Genomas Brasil), Frédéric Haziza (CRG)

2021-02-09: Second Meeting 2021

Chair: Alexander Senf, Rob Davies

Attendees “Name (Affiliation)”:  Frédéric Haziza (EGA-CRG), Gerrit Botha (H3Africa)

Cloud vendors - key management

Bioinformatics paper

Connect agenda - key management, someone should be aware and provide feedback to

Should there be a crypt4gh meeting at connect?

Crypt4GH Development Ideas document - future achievements

crypt4GH best practices - what are the issues for key management we’re looking at for key management specifically in the cloud

Local environment, private key

Shared enviro - shared security

Cloud enviro - submit file to bioinf pipeline, shared system, don’t have an account but want to submit files that are encrypted

Within that, found two issues:

1. In order for this to work for cryp4 specifically, personal encryption key is embedded, to access the file need private key of user -- not really cloud ready, want to keep private key unshared

1. Cloud providers do offer key management systems, eg. Amazon key management system, can add keys even aws staff can’t read it, hardware
2. Still have to extract to decrypt header, anyone has visibility of your machine, can extract
3. Also offer secure compute enclaves, AWS Nitro instance at Amazon, separate security hardened enclave, not hardware supported, but other cloud providers do offer that

> what we really should be thinking about is way to encrypt file header as a whole unit, current libraries, decrypt header in same process as rest of file, would like to take header and send off by function or REST call, ship encrypted header somewhere else, could be inside of enclave, could be unencrypted payload, no one would see it ever, decryption of that private info, but do get back less sensitive data key, shared among multi users anyway

Don’t want to ship entire decryption into …

Rob’s agent works that way already...secrecy is in the agent process only, file decryption key

Access is a socket, UNIX socket, internet socket, sends messages to it and gets answer back

Take that process and move to separate machine/subsystem ,that could work in theory

Argument for unix is ability to set permissions, makes slightly more difficult to get at

Difference between local system and runnin somewhere else

Could also use SSH, UNIX … interesting to see

One idea to make it work out who is trying to contact it, in process group that it expected everything to be in

Environment variable also needed to contact it ,has a key

Could also check that subprocess is in right process group which would make it difficult to use by someone not supposed to use it

Haven’t yet implemented that, might be tricky

Enclaves do give you tight control over who can access it, what code can run inside, locks all of that

Gerrit: Why don’t you use the current enclaves? Not secure enough? Or tech still being designed to fit in there?

Alex: standard itself doesn’t say anything about how we handle keys, download onto your computer, run analysis, need private key to decrypt file header and file itself

Problem came whent thought about shipping that to cloud

Cloud WS - if I ship file to WES, eg., how would the WES handle a crypt4GH, handling private key inside cloud enviro is key issue that keeps from us from cloud

GB: save key but if data is encrypted on cloud, then data is open, or do you not worry about that?

AS: data still encrypted any way stored, process that tries to read, decrypts on the fly in memory

FH: at EGA, imagine you have 3 services, all would like to open the files, separated the headers from the payload, payload are on disc, only recencrypt the header, no service has master key; I’d like to read file, can I? If yes rencrypt header with service

Put that service into cloud, start the process, include in the enclave an ephemeral private and public key, have a way to extract public, could use that service and send an encrypted header that would decrypt with its own key in enclave, don’t have to worry about storing key bc invented a new one, should be granted access…

File payload is on cloud ready to be decrypted if you encrypt the header, reencrypt the header fo that service

Eg., when receive file, ingestion process that decrypts and verifies the file, we just decrypt bec uses ega public key, uses service private key to decrypt,when done rencrypt header as master to save in db, send to QC process ,reencrypt for that process, payload always the same, cut out headers, swap headers all the time, rencrypt for that service

Reencrypt for users so they can download the files

AS: makes accessible to services rather than in’dl users; alternate idea, when use registers with specific enviro,do something like that ephemeral key tied to user’s identity, public version added to crypt4gh file before submitting to cloud, diff users could submit to same enviro, diff header for each, no one would have to share private key from local system with cloud

RD: diagrams may be needed to explain some of these :)

AS: all have similar ideas, make a nice presntation and discuss with cloud work stream, they would be the ones to know what is feasible from a cloud perspective

RD: most cloud services do support ways of storing keys, batch queuing system is the hard thing

AS: the main issue is simply to keep in’dl user’s keys separate, enclaves in middle so no one can watch public/private decryption happening

RD: how easy it to start things running on the enclave?

AS: Nitro costs not more than EC2 instance, may just try and play around with it to see how easy to get somethin running, other clouds have hardware supported enclaves, MS and google

And ssh inside just to see if I can send header in and get something back

AS: if fred could present this

GB: done some work with Federic on multi-receipient keys, testing, want to have out of it more - where can I get involved? Documentation? Presentations?

RD: Definitely need documentation!

GB: if there’s an ideal way to start, I can help. Location? Google drive or website? https://Crypt4gh.readthedocs.io 

This is python, what about java and C

GB to go through and see what needs updating

FH: C, Python, and also Rust (for java, it’s maybe just htsjdk) ; partner groups for EGA use Java and may also have “golang”????

https://github.com/EGA-archive/crypt4gh-rust 

Core part library with encryption function, rest is cosmetic, eg curl and libcurl

These crypt4gh in python does both, rust does both, golang is just library (?).

C use-case: postgres store headers in postgres db, sometimes need to decrypt, reencrypt, send, do that using c extension, but just headers, nothing related to the payload itself

Was writing lib-crypt4gh so any c project could use it, never finished bc only interested in the the header

AS: from usability pov, to help people use would be good to get a tutorial, python based is okay, write documentation on eg., here is how to compile samtools, extend to… here is my file, how to encrypt with my keys, how to use in normal processes, great start, could help move toward adoption

FH: still think we should reenforce crypt4gh fuse, use any tools, not just SAM,

RD: that’s another chapter in the manual

AS: could download all in fuse...but same process, encrypted on fly...setting that up and using it, would still like tools to be able to natively use it, but both is useful

GB: some tutorial and documentation for how to use from start to end, focus first on python then maybe running on fuse

https://github.com/EGA-archive/crypt4ghfs

https://github.com/EGA-archive/crypt4ghfs-rust

Coder said it runs 2x fast...need to check

I like that it works on linux and other places as well, nice for user, presented this to BSC about using fuse to look at files, could look at as if were decrypted

They loved it, better approach than tools natively decrypted

We are distributing in crypt4gh they will open using fuse, use whatever tool you want (at EGA), but how to make that safe in the cloud is the question

2021-01-12: First Meeting 2021

Chair: Alexander Senf, Rob Davies

Attendees “Name (Affiliation)”: Fred Haziza

2021-MM-DD: Template

Chair: Alexander Senf, Rob Davies

Attendees “Name (Affiliation)”:

Previous Minutes

2021 Meeting Minutes

2020 Meeting Minutes

2019 Meeting Minutes

2018 Meeting Minutes