Homec4science
Diffusion Genome Privacy - SHCS App (master) Browse

genopri-shcs/report/sections/deployment.tex
dc7495fb1b53master

Last Change
Raw File

deployment.tex
View Options

\chapter{Deployment into Production Environment}
%%%%%%%%%%%%%%%%%%%%%%%%%%
% State of the Project
\section{State of the Project}
\subsection{Swiss HIV Cohort Study}
The Swiss HIV Cohort Study (SHCS) \citep{shcs-intro} is an ongoing research project dealing with HIV infected adults. It aims to coordinate
\subsection{State of the Protocol}
In a first step, the genomic and non-genomic data are stored in SHCS data centers in plaintext only. The suceptibility tests are performed on plaintext. Hence the current configuration does not provide any privacy to SHCS patients.
Our goal is to deploy our improved scheme at the SHCS to provide efficient suceptibility tests and protect the privacy of the patients and MUs.
%%%%%%%%%%%%%%%%%%%%%%%%%%
% Constraints
\section{Constraints}
\subsection{Storage Infrastructure}
Medical and specially genomic data privacy is a highly important topic for medical data storage providers. As SHCS stores the genomic and non-genomic data on its servers, there are many security mechanisms put in place to restrict the access to the data. In consequence, getting granted a direct access to the databases storing the data or accessing our own application running within SHCS infrastructure was not possible in the timeframe of this project.
However a mitigation to this issue was found in collaboration with SHCS data center administrators. Instead of granting a direct access to their databases, they proposed to grant us access to web services within SHCS firewalls which could query SHCS databases. Also, they offered us the possibility to run our server applicaiton within SHCS firewall but with no access to the outside.
\todo[inline]{Describe the scheme}
\todo[inline]{Describe modifications to previous scheme}
\subsection{Client Infrastructure}
The client infrastructure is also subject to strict policies. In our initial setup, the client was running a MySQL database locally in order to store cryptographic keys as well as SNP weights per tests. MySQL is not installed by default on SHCS clients and installing a new software is again subject to strict policies. A mitigation found was to use the already available Microsoft Access database instead of MySQL database. As we use only very simple database declarations, the syntax of Microsoft Access does not change from MySQL.
%%%%%%%%%%%%%%%%%%%%%%%%%%
% Design
\section{Design}
\subsection{Web Service Limitations}
Which architecture of WS to use? Present DTDs and WSDL if available. Example of SOAP messages.
\subsection{Client Databases Migration to Microsoft Access}
Intro on what do client databases store.
Library limitation with Java to use MS Access as not deployable on any platform. Use UCanAccess library to handle simple transactions with MS Access databases.
\subsection{SPU Database Migration to Oracle}
%%%%%%%%%%%%%%%%%%%%%%%%%%
% Design
\section{Implementation}
\subsection{Preparaiton Work}
Prep work needed to be able to replace Paillier by EC-ElGamal. A first issue was that the cryptogrpahic classes were duplicated over the MU, SPU and CI applications. Group all classes within one project containing all helper, communication, database access and cryptographic classes. Then better separate the classes within every project. Make logic not dependent on crypto implementation or encrypted data format.
As the order and choice of tests done dependsd partially on the results obtained by some tests, the flow of a diagnostic is not known beforehand. In consequence, lots of methods were duplicated in order to run every deviation from the standard flow of a single unique test. A effert was also made to clearify the logic, better generalize the functions in order to allow more flexibility in the call of the functions.
\subsection{Replacement of Paillier by ECCEG Module}
\todo[inline]{Stopped here in sprint}
\subsection{Modification of Protocol}
In order to limit the complexity of the system, little modifications were put in place in order to reduce the calls the web services at SHCS.
\subsubsection{Pack the HLAs with SNPs and CFs}
Due to the separation of services of database queries and decryption, the HLAs are automatically packaged with the answer of the getMaterial \todo{add reference or correct name} call to \verb#Request Manager# Service.
This modification increases a bit the communication overhead to \verb#Decrypt# Service as the HLAs will have to be sent along the encrypted test results. However this slightly overhead simplifies a lot the deployment of the solution as it avoids the need of a third service which would query the database for HLAs and partially decrypt them.
\subsubsection{Query all SNPs for all Potential Tests}
There are some particular cases where you need to run more complex tests if the first results are not concluent (e.g. EFV PHARMACOKINETICS\_CYP2B6 or HIV Progression Test). The previous version of the protocol was running the first test and depending on the decrypted test results, running the subsequent tests. Due to the delay of the \verb#Decrypt# Service, this protocol is not longer satisfactory. The proposed solution is to get the required material for all potential tests at once. This implies again a communication overhead between the client and all services, but avoid stacking multiple decryption delays which would impact the end-user.
\subsubsection{Explain tradeoff between overhead and report leadtime}
%%%%%%%%%%%%%%%%%%%%%%%%%%
% Limitations
\section{Limitations}
\subsection{Message Level Security}
\subsection{Key Management}
c4science · Help