Я придумал сценарий для создания защищенных данных. Предположим, у меня есть публичный зашифрованный
файл, который любой может скачать. Но всякий раз, когда кто-то хочет расшифровать эти данные, он должен получить ключ от сервера
Чтобы сделать ключ нельзя поделиться. Ключ с сервера не сможет расшифровать
данные напрямую. Но данные должны быть расшифрованы с клиентом
закрытый ключ после того, как сервер не знает, что privateKey этих клиентов
Сделайте так, чтобы каждый раз при загрузке файла добавлялась случайная строка . Затем файл зашифровывается с помощью открытого ключа пользователя и симметрично с соответствующим хешем, сгенерированным той же самой строкой. Например, файл GPG внутри ZIP-файла, защищенного паролем.
Итак, Алиса скачивает Financial_Report_201809_d8a1b2e6.pdf.zip, а Боб скачивает Financial_Report_201809_ff2a91c3.pdf.zip.
Если они хотят расшифровать файл, им необходимо отправить серверу случайную строку, и сервер предоставит им пароль для внешнего ZIP. Затем они остаются с зашифрованным файлом, который может декодировать только их закрытый ключ.
Обратите внимание, что после расшифровки файла ничто не мешает им переслать файл в открытом виде кому-либо еще. С другой стороны, совместное использование зашифрованного PDF ничего не дает, так как им также нужно будет поделиться своим закрытым ключом.
Также обратите внимание, что, поскольку им нужно быть в сети, чтобы получить внешний пароль, и в конце у них остается файл с открытым текстом, это (почти) функционально эквивалентно файлу, загружаемому в открытом виде один раз. установлена личность пользователя .
Основные отличия:
- зашифрованный файл (PDF в приведенном выше примере), возможно, вообще не был зашифрован сервером. Возможно, он был предоставлен пользователем, который удовлетворен тем, что только он может прочитать файл обратно (хотя для любого другого пользователя нет смысла его скачивать).
- переданный файл очень надежно передан. Злоумышленник с полным доступом к потоку данных не сможет декодировать файл (но это не более, чем можно получить, просто зашифровав его с помощью открытого ключа пользователя - дополнительная стадия ZIP не требуется).
UPDATE
Вы хотите зашифровать весь файл только один раз (для всех пользователей), а затем отправить тот же файл Алисе и Бобу, и им требуется два разных ключа при расшифровке время. Проблема здесь в том, что ключ Алисы также будет работать с файлом Боба, поскольку это тот же файл . Здесь нет никакой магии, которая может сработать, если вы не сможете скрыть некоторые детали процесса дешифрования (например, использовать программу, которой вы управляете, и которую нельзя отлаживать, и которая всегда будет подключаться к вашему серверу: предложение, которое имеет последовательно показано, что проигрывает ).
Если вы хотите ограничить стоимость шифрования, вы можете отправить массивный файл как с симметрично зашифрованными данными (всегда одинаковыми), так и с очень короткими, асимметрично зашифрованными ключами (всегда разными), но все же вы будете уязвимы для захваченного расшифрованного ключа:
[ RSA(ALICE.PUB, "SQUEAMISH OSSIFRAGE" ][ RIJNDAEL("SQUEAMISH OSSIFRAGE", LARGE FILE) ]
В приведенном выше сценарии некоторые программы должны прочитать заголовок шифрования и расшифровать пароль «Squeamish Ossifrage», а затем продолжить расшифровку (например, воспроизведение) дополнительной полезной нагрузки без перехвата пароля. Это означает, что вам необходимо предоставить программу самостоятельно.
Это функционально эквивалентно программе, подключающейся к серверу и загружающей «да» или «нет» на вопрос (соответствующим образом зашифрованный, подписанный и защищенный) «Я игрок Алисы. Могу ли я расшифровать и воспроизвести» Never Wanna Give You Up.avi '? ", при этом пароли или открытые ключи не известны и не передаются, кроме секрета, разделяемого игроком и сервером Алисы.
ОБНОВЛЕНИЕ II
Если целью является сохранение ресурсов шифрования, шифрование может быть выполнено на стороне клиента, как указано в комментарии:
- файл зашифрован один раз с помощью специально сгенерированного личного ключа.
- закрытый ключ хранится в двоичном файле (мы должны предположить, что он не может быть взломан).
- пользовательдолжен предоставить свой открытый ключ для расшифровки для работы
- программа может проверить открытый ключ из хранилища (или, альтернативно, пользователь может предоставить открытый ключ на сервер, который будет генерировать и отправлять двоичный файл)файл для загрузки)
- затем программа выполняет как дешифрование, так и повторное шифрование
- пользователю остается файл, зашифрованный его открытым ключом, который он один может расшифровать.
ОБНОВЛЕНИЕ III
Чтобы файл открытого текста никогда не был открыт (т. Е. Не имеет значения утечка алгоритма), вы можете разработать следующую схему.Имейте в виду, что я не криптограф, и могут быть все виды побочных каналов, оставшихся открытыми.
- Вы готовите таблицу преобразования, которая отображает каждое 16-разрядное слово в другое 16-разрядное слово.Это разновидность симметричного шифрования, даже если вы используете две обратные матрицы для кодирования и декодирования.Каждая матрица содержит все возможные 16-разрядные слова, что означает 65536 значений, и, следовательно, имеет размер 128 КБ.
- Файл шифруется один раз с помощью матрицы шифрования.Без матрицы дешифрования файл непригоден для использования.
- Пользователь должен отправить вам свой открытый ключ.
- Вы готовите матрицу трансмогрификации, шифруя каждое слово этим ключом, и используете значение дешифрования.в качестве индекса.
Так, например, скажем, первое слово файла открытого текста - A18B.В матрице шифрования после скремблирования позиция A18B будет содержать, скажем, 701C, а матрица дешифрования, следовательно, в позиции 701C будет содержать a18b.
У пользователя есть файл, начинающийся с 701c... который бесполезен.
Пользователь отправляет вам свой открытый ключ, и вы запускаете 65536 шифрований для всех слов от 0000 до ffff.Затем вы определяете, что шифрование a18b - 791c.Вы готовите матрицу перекодирования, в которой 791c находится в позиции 701ct.
Затем вы отправляете пользователю эту матрицу, имеющую 128 Кбайт, где позиция 701cth равна 791c.
Пользователь запускаеточень быстрая трансмогрификация, и в ней остается файл, начинающийся с 791c (так как 701c стал 791c - я по ошибке выбрал два аналогичных значения в моем примере, что не имеет значения).Это значение, после расшифровки его закрытым ключом , даст a18b, которое является «читаемым» значением.
Теперь у пользователя есть файл, который был зашифрован его открытым ключом.Значение a18b нигде не появлялось.
Осталось только расшифровать файл, используя его личный ключ и размер кодового блока 16 бит. Эта операция будет выполняться клиентом и будет довольно медленной , и по этой причине обычно большой случайный быстрый симметричный ключ кодируется RSA и используется для симметричного быстрого шифрования большого файла, который может быть быстрорасшифровывается после того, как закрытый ключ разблокировал симметричный ключ.
Пользователь не может отправлять кому-либо 128 КБ, поскольку они бесполезны без закрытого ключа.
(Проблема по-прежнему заключается в том, чтотеперь пользователь может расшифровать файл с помощью своего закрытого ключа и отправить его, даже если он громоздкий, поскольку это очень большой файл).