Stormpath generates and assigns it’s own unique identifier to each user for it’s own internal use, which Bridge uses as a publicly accessible account identifier. In addition, for each user in a study, the Bridge service generates its own pair of universally unique identifiers (UUIDs). The first UUID is called “Bridge account ID” and is generated by the Bridge Server on account creation, encrypted, and saved in Stormpath. Encryption uses 256-bit AES, GCM-mode. The AES cipher is created using Apache Shiro. The actual encryption is provided by the latest version of Bouncy Castle. Bridge servers are currently deployed as Heroku stacks. As a result, the encryption key is set as an environment variable on the Heroku admin console to pass to the Bridge servers. Only authorized Sage employee the Bridge technical team have access to the Heroku admin console. Additionally, each stack (local, development, staging, or production) uses is assigned its own encryption key. The second UUID, called “participant health code”, is used internally by Bridge as the key to user’s study data. If the same user enrolls in multiple studies, multiple account IDs and health codes will be generated to keep data for each study isolated. A one-way mapping is set up from account ID to health code. Currently the mapping is implemented as a DynamoDB table with the account ID as the hash key. The workflow is illustrated by the following diagram:
...
A risk is that an attacker with access to the Dynamo ID map could scan the table in whole and then reverse the map. With BRIDGE-177, IAM rules will be set up to forbid querying and scanning the DynamoDB table that holds the one-way map (See AWS documentation). With BRIDGE-178, participant health codes will be stored encrypted in AWS. And with BRIDGE-179, if we introduce user's password hash into the encryption, even the master key holder would not be able to reverse the map.