Transfer of Study Data to Bridge

Bridge will store encrypted study data in a combination of AWS DynamoDB and AWS Simple Storage Service (S3).  The only unencrypted data stored in either system will be the study participant ID, the study ID, the ID of the data module (defines the data schema), and the time the data was captured, stored in Dynamo for each time point at which data is collected.  This allows Bridge to support time-range queries for a user to retrieve his / her own data.  This will allow clients to build complete histories for customers, even if data is collected from multiple devices / interfaces.  Large binary study data such as voice recordings, and bundled uploads will be stored in S3, using Amazon’s server-side encryption. Amazon manages the server-side encryption transparently for us.  It currently uses 256-AES-GCM.

Process for transferring health data from client to Bridge server:  1. Data is encrypted by the mobile client using Cryptographic Message Syntax (CMS).  The CMS public key is generated by Sage using 2048-bit RSA and is supplied to the app developer.  Each study is assigned a different public key.  Data will be cached on the device for upload to the server pending network availability.  2. A background process on the client OS calls the service to get a location to upload data to, returned as URL pointing to an AWS S3 bucket dedicated for file upload that is part of the Bridge stack.  3. Upload of the encrypted data file over S3 is via HTTPS.  4. A call to Bridge Server informs the server that the upload process is complete.  5. An asynchronous server process decrypts and validates the file using a private key held only by Sage Bionetworks.  6.  Metadata is written to Dynamo to record the user, study, and time of data collection. Research data is written to a S3 bucket dedicated for each particular study.  For more details see our policies around Key Management.

Future Extensions

Certificate Pinning

Certificate pinning can be beneficial at two places.  One is where the Bridge servers calls Stormpath.  Current implementation relies on the Java 7's trust store to authenticate Stormpath.  For better security, we could pin Stormpath's certificate.  The other place is where the mobile client calls Bridge.  Bridge server's certificate could be pinned to reduce the risk of man-in-the-middle attacks. This improvement is being tracked by BRIDGE-369.