[UC] End-to-end encryption (in/out data transfer and storage) #44
Description
As a Pod user ...
... I want data transfer to and from my Pod to be encrypted, in a way that others cannot decrypt if not authorised by me. The data will therefore also remain encrypted while in Pod storage, and not even the Pod provider will be able to access the unencrypted content unless I allow it ...
... So that I am confident that my data is secured against any and all actors, and that I have full control over who I allow to access unencrypted data. This is to ensure protection against all kinds of malicious intent.
Preconditions:
What conditions must be in place or assumed before this use case can begin?
A user has a Pod, and has uploaded data to it with confidence that all data handling will be securely encrypted.
Trigger:
What (user or system) event or action initiates this use case?
The user wishes to transfer some data from local storage into their Pod, of from their Pod to an external location, such as an online service or another Pod.
Actors:
Describe the primary actor, and any other relevant actors involved in this use case
The Pod/data owner is the primary actor. The data receiver is the secondary actor. In the case of transferring data from local storage into a Pod, the receiver is the Pod provider. In the case of transferring data from a Pod to an external location, the receiver is the external service provider, which may also be a Pod provider.
Distinction:
What unique challenges or distinguishing factors (like technical issues, user experience needs, workflow integration, etc.) are associated with this use case?
Technically the process must be truly secure, robust and in line with current best cryptographic practices. Not only that, but it should be as future-proof as realistically possible, being thoroughly integrated into the fundamental approach of data transfer rather than bolted on.
In terms of user experience, the average user should have no assumed technical knowledge and no need to understand or be aware of data transfer and storage protocols. To them, any Pod activity they engage in should be implicitly considered as safe, and there should be no sense that it is anything but.
Scenario:
Describe an ideal or happy-case scenario where this use case would play out as intended.
A data owner transfers as much or as little data to and from a Pod as they like, and it is never at risk of being decrypted by anyone not allowed by the data owner, including the Pod provider or an intercepting third party.
Alternative case(s):
What alternative flows or variations should the system handle for this use case?
Both data transfer and storage should be dealt with in tandem to ensure that they are designed to mutual benefit, and that this is truly an end-to-end process.
Error scenario:
What unexpected issues or errors might arise, and how should the system handle them?
A user's private key for cryptographic transfer may become compromised, such as if the user unwittingly transfers it outside of their own environment. In this case, it should be simple for the user to replace keys as necessary, with little to no disruption in their Pod use. To further inhibit such cases, users should be made aware of the basic aspects of the process that are under their control (i.e. key handling), and non-expert users in particular should be screened from details and inhibited from mis-steps as much as possible.
Acceptance Criteria:
What conditions or criteria must be met for this use case to be considered successfully handled? What limitations are acceptable?
Cryptographic data transfer and storage is implemented by all Pod providers as standard, being inherent in the specification. This ultimately leads to no data breaches via means currently known to security experts, and a deep sense of trust in the system by the user community at large, both existing and potential. This will help uptake of the initiative as a major selling point.
References:
List any relevant resources or examples that could inform this use case, possibly from other domains or solutions.