Как разработать безопасную платформу для хранения/обмена файлами

Как подразумевает заголовок, я хотел бы разработать платформу для безопасного хранения и обмена файлами. Это абстрактный вопрос дизайна, поэтому детали, касающиеся языков программирования или платформ, не особенно актуальны, если они не представляют собой единственный вариант для хорошего дизайна.

Таким образом, приложение должно одновременно выполнять все следующие условия:

1. Никакие данные не могут храниться на локальных устройствах пользователей (т.е. ноутбук, телефон и т.д.), кроме как в течение текущей сессии
2. Пользователь может получить доступ к файлу по запросу с любого устройства
3. Сервер или неавторизованные пользователи не могут прочитать хранимый файл

Как мне следует разработать такое приложение разумным образом? И под разумным я подразумеваю среду известных угроз, и самый большой риск — это человеческая ошибка, так что, если утечка когда-либо произойдет, она ограничится одним файлом на одного пользователя, а не всеми файлами пользователей или всей базой данных.

На данный момент у меня есть следующие идеи относительно дизайна:

1. Пользователь получает доступ к приложению через стандартный HTTPS
2. Пользователь регистрирует аккаунт с именем пользователя и паролем
3. Сервер хранит имя пользователя и хэшированный + соленый пароль
4. Когда пользователь хочет загрузить файл, выполняются следующие шаги для каждого отдельного файла:

• Интерфейс (мобильное приложение / веб-страница / другое) запрашивает у пользователя пароль, специфичный для файла
• Интерфейс генерирует пару ключей и защищает закрытый ключ с помощью предоставленного пользователем пароля
• Интерфейс шифрует файл с использованием открытого ключа
• Сервер получает и хранит: зашифрованный файл, открытый ключ, защищенный закрытый ключ и хэш пароля для конкретного файла
• Любая информация удаляется из локального хранилища на стороне пользователя

5. Когда пользователь хочет просмотреть файл, выполняются следующие шаги для каждого отдельного файла:

• Пользователь входит в свой аккаунт, используя имя пользователя и пароль
• Учетные данные проверяются сервером
• Пользователь вводит имя файла и пароль в интерфейсе
• Интерфейс отправляет запрос с именем файла и паролем
• Сервер ищет имя файла и сравнивает и проверяет пароль по соответствующему хранимому хэшу
• Если все в порядке, сервер отправляет зашифрованный файл, открытый ключ и защищенный закрытый ключ обратно пользователю
• Интерфейс расшифровывает файл с использованием закрытого ключа и пароля и показывает данные пользователю.
• После окончания сессии данные удаляются из локального хранилища на стороне пользователя.

Является ли это безопасной настройкой или это бесполезно/избыточно? Моя самая большая озабоченность — это хранение закрытых ключей на сервере. Имеет ли это вообще смысл? Достаточен ли пароль для защиты закрытого ключа, или его можно использовать для восстановления данных даже без знания пароля? Какие существуют другие варианты, если таковые имеются?

Существует также четвертое, не обязательное условие, что пользователь должен иметь возможность поделиться конкретным файлом с другим доверенным пользователем. Теперь я подумал о следующем подходе:
Первый подход заключается в создании копии для другого пользователя (будущие изменения данных не будут отражены):

1. При создании запроса на общий доступ, владелец файла (Пользователь 1) (предполагая, что файл уже получен от сервера) запрашивает открытый ключ у Пользователя 2
2. Пользователь 2 генерирует пароль и пару ключей, которые отправляются на сервер
3. Сервер отправляет полученный открытый ключ пользователю 1
4. Пользователь 1 шифрует файл, используя открытый ключ пользователя 2, и отправляет его на сервер
5. Пользователь 2 теперь может получить доступ к файлу, как описано ранее

Меня беспокоит эта настройка (в дополнение к проблемам из первой части), увеличит ли она шансы на экстраполяцию содержимого файла и полностью обойти шифрование, если количество копий достаточно велико? Или это не является проблемой?

Редактирование 1: чтобы привести пример, вы можете представить пациента, который хранит некоторые медицинские записи конфиденциально, так что даже сервер не может их прочитать. И хочет поделиться ими с врачом, чтобы только он и врач могли их просмотреть.

Я понимаю, что это очень абстрактный вопрос, поэтому, пожалуйста, не стесняйтесь запрашивать детали/улучшать вопрос. Чтобы подытожить, какие были бы хорошие практики для таких требований, если это вообще возможно? Является ли описанный выше дизайн безопасным? Какие есть другие варианты?

Хотя я могу поверить, что эта конструкция приводит к системе, где даже сервер не может прочитать содержимое, она сталкивается с гораздо большей проблемой — людьми.

Пароли ужасны. Разный пароль для каждого файла, который есть у пользователя? Я даю среднему пользователю 2 или 3 документа, прежде чем пароль станет 1234. Всё, что нужно злоумышленнику, это сбросить зашифрованные файлы и провести атаки по словарю.

Хранить зашифрованные файлы таким образом, чтобы сервер мог их расшифровывать, нормально, если это правильно обрабатывается (KMS, тщательно подобранные списки администраторов, наименьшие привилегии и т. д.). Если они должны быть зашифрованы таким образом, что сервер не может их расшифровать, правильно сгенерированные и управляемые пользователем ключевые материалы являются гораздо более надежным предложением.

Если под «утечкой» вы имеете в виду, что кто-то другой получает контроль над сервером в вашей формуле, то база данных может зашифровать файлы перед передачей их на сервер.

Для шифрования вы можете использовать открытый ключ сертификата пользователя. Это означает, что вам нужно использовать HTTPs с взаимной аутентификацией на сервере и предоставить базе данных копию хранилища доверия. Это исключило бы необходимость в пароле для каждого файла, передаваемого пользователю.

Вы можете использовать тот же подход для обмена файлами между пользователями, используя клиентское приложение, способное выполнить шаг шифрования выше и имеющее доступ к хранилищу доверия, содержащему сертификаты пользователей.