Можно ли шифровать с помощью закрытого ключа / расшифровать с помощью открытого ключа?

Question

[Отказ от ответственности: я знаю, если вы знаете что-нибудь о крипто, вы, вероятно, собираетесь сказать мне, почему я делаю это неправильно - я сделал достаточно Googling, чтобы знать, что это типичный ответ.]

Предположим следующее: у вас есть центральный орган, который хочет выпустить файлы cookie для входа в данный домен.В этом домене вы не обязательно доверяете всем, но у вас есть несколько ключевых конечных точек, которые должны быть в состоянии прочитать cookie.Я говорю несколько, но на практике это число «доверенных» партнеров может быть большим.Файл cookie не содержит много информации - имя пользователя, временную метку, срок действия, случайное число.Конечно, он должен оставаться небольшим по соображениям производительности, даже после шифрования (в пределах разумного).Теперь есть две проблемы безопасности:

1) Мы не доверяем каждому веб-серверу в этом домене пользовательские данные.По этой причине возможность чтения cookie-файлов должна быть ограничена этими доверенными партнерами.2) Хотя мы доверяем этим партнерам защиту данных наших пользователей, мы все же хотели бы, чтобы центральная точка власти была не поддающейся контролю (опять же, в разумных пределах).

Теперь, если мы сгенерируем закрытый ключ RSA дляавторизовать и держать его в секрете, а также распространять открытый ключ только среди «доверенных партнеров», мы должны иметь возможность шифровать его с помощью закрытого ключа и сделать его доступным для чтения любому, кто имеет открытый ключ.Что мне неясно, так это то, будет ли по-прежнему необходимо подписывать сообщение или дешифрование будет свидетельством того, что оно было сгенерировано с помощью закрытого ключа?Является ли это каким-либо способом, в котором эта схема была бы лучше или хуже, чем распространение симметричного ключа среди всех участвующих сторон и использование его для шифрования при использовании личного ключа только для подписи?И, конечно, не стесняйтесь рассказывать мне о том, что это глупая идея, но имейте в виду, что практические аргументы, вероятно, будут более убедительными, чем повторение Алисы и Боба.

О, и указатели реализации приветствуются,хотя можно найти основы в Google, если бы были какие-то "ошибки", которые были бы полезны!

Answer 1

Нейт Лоусон объясняет здесь и здесь , почему вы не можете безопасно использовать открытый ключ в качестве закрытого секретного ключа дешифрования (это тонкий момент и большая ошибкадругие сделали до вас, так что не расстраивайтесь!).

Просто используйте ваш открытый ключ для подписи на подлинность и отдельный симметричный ключ для секретности.

Я прочиталДостаточно интересных атак на системы с открытым ключом и, в частности, RSA, чтобы я полностью согласился с таким выводом:

Криптосистемы с открытым ключом и, в частности, RSA чрезвычайно хрупки.Не используйте их по-другому, чем они были задуманы.

(Это означает: зашифруйте открытым ключом, подпишите закрытым ключом, а все остальное играет с огнем.)

Приложение:

Если вы заинтересованы в уменьшении размера получаемых файлов cookie, вам следует рассмотреть возможность использования ECDSA вместо RSA для получения подписей - подписи ECDSA значительно меньше, чем подписи RSAэквивалентный фактор безопасности.

Answer 2

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

Обычный способ состоит в том, что орган власти применяет цифровую подпись к файлам cookie и что файлы cookie шифруются ключом, известным доверенным веб-серверам. То, о чем вы думаете, выглядит следующим образом:

• Существует модуль RSA n и два обычных показателя RSA d и e (такие, что ed = 1 по модулю p-1 и q-1 , где n = pq ). Центральный орган знает d , доверенные веб-серверы знают e , модуль n является общедоступным.
• Файл cookie обрабатывается центральным органом власти, добавляя его в целое число c по модулю n и вычисляя s = c ^ d mod п .
• Доверенные веб-серверы получают доступ к данным cookie, вычисляя c = s ^ e mod n .

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

• Для базовой безопасности e должно быть большим. В обычных описаниях RSA e является публичным показателем и является небольшим (например, e = 3 ). Небольшой показатель не является проблемой, если он общедоступен, но, поскольку вы не хотите, чтобы содержимое файлов cookie было доступно третьим сторонам, вы должны сделать e достаточно большим, чтобы противостоять исчерпывающему поиску. В то же время доверенные веб-серверы не должны знать p и q , только n . Это означает, что доверенные веб-серверы должны будут вычислять вещи с большим модулем и большим показателем, без знания факторов модуля. Это кажется незначительным моментом, но оно дисквалифицирует многие библиотеки реализации RSA. Вы будете "по своему усмотрению", с большими целыми числами (и всеми проблемами реализации, известными как "утечки побочного канала").
• Сопротивление подписи RSA и стойкость шифрования RSA хорошо изучены, но не вместе. Случается, что заполнение имеет важное значение, и вы не используете одну и ту же схему заполнения для шифрования и для подписей. Здесь вам нужна схема заполнения, которая будет хороша как для подписи, так и для шифрования. Криптографы обычно считают, что хорошая безопасность достигается, когда сотни обученных криптографов рассматривали схему в течение нескольких лет и не обнаружили явной слабости (или исправили обнаруженные слабости). Схемы домашнего приготовления почти всегда не обеспечивают безопасности.
• Если многие люди знают секрет, то он больше не является секретом. Здесь, если все веб-серверы знают e , вы не можете отозвать привилегии доверенного веб-сервера, не выбрав новый e и не сообщив новое значение всем оставшимся доверенным веб-серверам. Эта проблема может возникнуть и у общего симметричного ключа.

Проблема обеспечения конфиденциальности и проверяемой целостности в том же виде в настоящее время изучается. Вы можете посмотреть signcryption . Установленного стандарта пока нет.

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

Для части подписи вы можете использовать DSA или ECDSA: они дают намного более короткие подписи (обычно 320 бит для сигнатуры безопасности DSA, эквивалентной 1024-битной подписи RSA). С точки зрения центрального органа, ECDSA также позволяет повысить производительность: на моем ПК, используя одно ядро, OpenSSL выделяет более 6500 сигнатур ECDSA в секунду (в кривой NIST P-192) и «только» 1145 сигнатур RSA в второй (с 1024-битным ключом). Сигнатуры ECDSA состоят из двух 192-битных целых чисел, то есть 384 битов для кодирования, тогда как сигнатуры RSA имеют длину 1024-бит. ECDSA в P-192 считается, по крайней мере, сильным и, вероятно, более сильным, чем RSA-1024.

Answer 3

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

Самого шифрования недостаточно. Откуда вы знаете, что дешифрованный messege - это то, что должно быть? Расшифровка файла cookie, зашифрованного с помощью правильного ключа, безусловно, даст «правильный» файл cookie, но что произойдет, если вы расшифруете файл cookie, зашифрованный с помощью неправильного ключа? или просто какие-то бессмысленные данные? ну, вы можете просто получить печенье, которое выглядит действительным! (временные метки находятся в диапазоне, который вы считаете допустимым, имя пользователя допустимо, случайное число ... э-э ... число и т. д.).

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

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

Answer 4

Ответ на ваш вопрос "будет дешифрованием свидетельством того, что он был сгенерирован с использованием закрытого ключа" , ответ "да", если получатель может выполнить простую проверку данных. Скажем, у вас есть «Имя пользователя: Джон, отметка времени: , срок действия: дд / мм / гггг». Теперь, если неправильный открытый ключ используется для расшифровки, вероятность того, что вы получите «Имя пользователя: <несколько букв>, отметка времени: <только цифры>, срок действия: ?? / ?? / ????» это ноль. Вы можете проверить с помощью регулярного выражения (регулярное выражение), например «Имя пользователя: [a-zA-Z] +, отметка времени: [0-9] +, expiry: ....», и отбросить его не удастся. Вы даже можете проверить, находится ли день между 1 и 31, месяц - между 1 и 12, но вы не сможете его использовать, так как регулярное выражение обычно приводит к ошибке «Имя пользователя:», если используется неправильный открытый ключ. Если проверка прошла успешно, вам все равно нужно проверить временную метку и убедиться, что у вас нет повторной атаки.

Однако учтите следующее:

1. Шифрование с открытым ключом RSA не предназначено для массового шифрования структурированных данных, поскольку оно может быть использовано злоумышленником. Криптография с открытым ключом обычно используется двумя способами: 1) для безопасной передачи симметричного ключа (который по определению не имеет структуры), который будет использоваться при массовом шифровании; это делается путем шифрования симметричного ключа с использованием открытого ключа и 2) цифровой подписи документа путем шифрования не документа, а хеша документа (опять же чего-то, что не имеет структуры) с использованием закрытого ключа. В вашем случае вы шифруете cookie, который имеет определенную структуру.
2. Вы полагаете, что открытый ключ не попадет в руки не тому человеку или организации.
3. Шифрование с открытым ключом примерно в 1000 раз медленнее, чем шифрование с симметричным ключом. Это не может быть фактором в вашем случае.

Если вы все еще хотите использовать этот подход и можете распространять открытый ключ только среди «доверенных партнеров», вы должны сгенерировать случайный ключ сеанса (т. Е. Симметричный ключ), зашифровать его, используя закрытый ключ и отправить всем получателям, которые имеют открытый ключ. Затем вы шифруете cookie с помощью ключа сеанса. Вы можете периодически менять ключ сеанса. Чаще вы также можете изменить открытый ключ: вы можете сгенерировать новую пару открытого / закрытого ключа и зашифровать открытый ключ с помощью сеансового ключа и отправить его всем получателям.

Answer 5

Открытые ключи по определению являются открытыми. Если вы шифруете с помощью закрытого ключа и расшифровываете с помощью открытого ключа, это не безопасно для посторонних глаз. Все это говорит: «эти данные поступают от лица X, у которого есть закрытый ключ X», и любой может проверить это, потому что другая половина ключа является открытой.

Что может помешать кому-то, кому вы не доверяете, разместить открытый ключ X на сервере, которому вы не доверяете?

Если вам нужна защищенная линия связи между двумя серверами, вам нужно, чтобы все эти доверенные серверы имели свои собственные пары открытого / секретного ключей, мы скажем пару ключей Y для одного такого сервера.

Сервер X может затем зашифровать сообщение с помощью закрытого ключа X и открытого ключа Y. Это говорит о том, что «сервер X отправил сообщение, которое мог прочитать только Y, а Y мог проверить, что оно было от X».

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

Это то, что делает SSL. Для установки ключа сеанса используется криптография с открытым ключом.

Как говорится, используйте библиотеку. Этот материал легко испортить.

Answer 6

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

Answer 7

Полагаю, вы доверяете «доверенным партнерам» в расшифровке и проверке файлов cookie, но не хотите, чтобы они могли создавать свои собственные файлы cookie? Если это не проблема, вы можете использовать гораздо более простую систему: разослать секретный ключ всем сторонам и использовать его как для шифрования куки-файла, так и для его создания HMAC. Нет необходимости в шифровании с открытым ключом, не нужно использовать несколько ключей.