User management and Crypto Key Management

Key management is the process of administering or managing cryptographic keys for a cryptosystem. It involves the generation, creation, protection, storage, exchange, replacement and use of said keys and with another type of security system built into large crypto Systems, enables selective restriction for certain keys.

CareBud project is not only interaction between single user and the cloud. It's a case where users also can interact with each other where they can share their information and apply sophisticated access rules such as (Reading, Writing and Modifying) which mean plenty of encryption and decryption processes and crypto keys need to be shared during that.

Security is very important matter when developing applications. How do you encrypt data and manage encryption keys in your application? Successful key management is critical to the security of a cryptoSystem. This is where KMS’s come into play. A key management system (KMS, see methodologies section p 7), also known as a cryptographic key management system (CKMS), is an integrated approach for generating, distributing and managing cryptographic keys for devices and applications.

In our scenario patient, P1 will always initialize the relation with other user account types, let’s assume that D1 is a doctor account. The moment P1 creates his/her account, the system will direct him to a new screen so P1 can select the wanted doctor to monitor and advise him when critical health issues come to the surface. In favor of that P1 has to share his/her crypto key with D1 which means the user generated key will be shared to D1 directly.

We need to manage users’ crypto keys in the system and keep it secure from any attacks or hijacking. From the examples used by AWS and other security companies, we came up with a plan to apply KMS in client side which will be more secure and less crypto key needed in our system. When D1 wants to access P1 health status reports or any other reports, he will not be able to access that until he got permission which will be managed by Access Controls System (ACL ...see methodologies section p 7) after that D1 will be required to decrypt P1 data which is encrypted by P1 crypto key. The whole process when P1 create his account till other part need to access P1 account will be explained in the next part.

The relation between P1 and D1 initialised the moment P1 select D1 as doctor to monitor and advise him through the system, in the other hand when D1 also accept that request from P1 at the moment the system will generate shared key (MasterKey) between P1 and D1 then it will generate document for that relationship which will be encrypted using that key then post it to the cloud backend.

let SharedKeyAccess = { 
relationID: "Id Created When Relation between two parts initialized", 
patientID : "first part who initialized the relation (encrypted format)", 
patientKey :"patient crypto key in (encrypted format)", 
doctorID : "second part who in the relation (encrypted format)", 
doctorKey :"doctor crypto key in (encrypted format)", 
createdDate : " date of creation", 
RelationStatus:"relation status (could be Active or Inactive)" 
}

//SHARED KEY ACCESS TABLE FORMAT

The above example shows the structure for SharedKeyAccess document which will be posted when the relation formed. Key management process and that document are handled in the project twice, first after the patient passes his signup page and the second if the patient needs to add a new doctor to the list during the app life.

When Patient (P1) sign up in the first place after submitting, he will be directed to a new screen that includes all the doctors available in the system then a request will be created it with the selected doctors which will be posted to the cloud backend to notify the chosen doctors, after confirmation received from a particular doctor (D1) MasterKey will be created between P1 and D1.

MasterKey(D1,P1) = generateKey(D1P1 ShareIds)

Next SharedKeyAccess document will be created upon that and it will be encrypted using the created MasterKey. As a result, a request with the encryptedData will be posted to the cloud backend.

sharedKeyAccessDocument = SKAD(P1_id,P1_Key,D1_id, D1_Key, relationStatus)
encryptedData = Fbe.decrypt(Pattern, sharedKeyAccessDocument, MasterKey(D1,P1))

Process for creating masterKey and sharedKeyAccess in the application

The process of creating SharedKeyAccess document and establishing the relationship between two parties can be concluded with the following steps:

1. Patient P1 will add a new doctor to the list.

2. CareBud app will create request to that Doctor D1.

3. The request will be posted to the cloud backend for further processing.

4. D1 will be notified and on accept he will trigger a replay to create MasterKey.

5. App will create Masterkey then it will create Shared Key Access Document.

6. App will encrypt shared key access document then it will be stored in the cloud backend.

7. The SKA document will be created in the cloud and response will be sent to the P1 for confirming the relation between P1 and D1.

In the other hand the same process will be done for users if they want to access shared data they should have other parties’ crypto keys, to clarify the idea, the following diagram will explain more.

Diagram shows process when user need to access other user data

The diagram above shows that doctor D1 want to access to patient P1 to perform any task such as (Read, Write, Modify). D1 will create request to get P1 data, the system will check the access right for that operation, then it will send a request to CarBud Backend. The backend response will include P1 data in encrypted format, which will only be decrypted with P1 generated key. Furthermore, another request will be fired to the backend to get a document called (SharedKeyAccess) and the response for this call is totally encrypted data. SharedKeyAccess document includes information and crypto keys about two parties that share data with each other, this data can be decrypted using a MasterKey which only generated using the relation between D1 and P1.

MasterKey(D1,P1) = generateKey(D1P1 ShareIds)
P1 PlainData = Fbe.decrypt(Pattern, encryptedData, MasterKey(D1,P1))

This process can be done in eleven steps:

1. Doctor D1 need to access Patient P1 data and information.

2. System will check users access control and it required to be authenticated.

3. System will send request to the cloud backend to get P1 data.

4. The response from the backend will include P1 data in encrypted format.

5. The system will check the relation between D1 and P1 for decrypting that data.

6. CareBud app will try to check the existence for MasterKey so it can be processed further.

7. Request to the cloud will be fired to get SharedKeyAccess document using D1 and P1 account Ids.

8. The backend will response with SharedKeyAccess document which is totally encrypted.

9. The App will start to decrypt SharedKeyAccess document data using MaterKey that been generated using the relationship between D1 and P1.

10. After getting P1 crypto key using MasterKey, D1 will be able to decrypt P1 data.

11. Data will be reflected in D1 screen as response to an action.

That’s how to manage the keys and access right in CareBud system using KMS to ensure best way of security, and also with the help of Access control rules which will be explained in the next part.