Матрицы. Основные понятия. Виды матриц

Пороговая (k, n)-схема разделения секрета. Схема Shamir и задача интерполяции многочлена.

Управление секретами. Ключи и пароли, их энтропии. Принцип Kerckhoffs и длина ключа (пароля). Статические и сеансовые ключи, способы их получения. Слабые ключи (пароли) и атака по словарю. Сравнение длин ключей симметричных и асимметричных криптосистем. Генерация криптографически стойких паролей и случайных чисел.

Алгоритм цифровой подписи ElGamal. Пример постановки и верификации подписи.

Алгоритм цифровой подписи RSA. Пример постановки и верификации подписи.

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

Пример: p=7, q=13, m=10

n=7*13=91;

e=17;

Расширенный алгоритм Эвлида:

a	b	c	d	x1	x2	y1	y2
							-4
					-4	-4

- подпись ставится на секретном ключе

- подпись проставлена

- проверка подписи производится на открытом ключе

- подпись успешно проверена

Управление секретами:

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

2) Для предотвращения атак полным перебором используются динамические(сеансовые) ключи, действующие только определенное время.

Сеансовые (сессионные) ключи — ключи, вырабатываемые между двумя пользователями, обычно для защиты канала связи. Обычно сеансовым ключом является общий секрет — информация, которая вырабатывается на основе секретного ключа одной стороны и открытого ключа другой стороны. Существует несколько протоколов выработки сеансовых ключей и общих секретов, среди них, в частности, алгоритм Диффи — Хеллмана. Преимущество их в том, что даже, если у Евы и будет возможность раскрыть ключ впоследствии, по окончанию сеанса он потеряет значимость и более никогда применяться не будет. Использование сеансовых ключей, позволяет использовать настоящие (статические) ключи только изредка, в основном для обмена сеансовыми, таким образом, значительно снижается число зашифрованных сообщений попадающих в руки злоумышленника, а ведь многие методы криптоанализа требуют наличия определенного числа сообщений зашифрованных на одном ключе, для его взлома.

В компьютерной индустрии обычно оценивают сложность пароля в терминах информационной энтропии (понятие из теории информации), измеряемой в битах. Вместо количества попыток, необходимых, чтобы точно угадать пароль, берется логарифм по основанию 2 от этого числа и называется количеством "битов энтропии" в пароле. Пароль со, скажем, 42-битной сложностью, посчитанной таким путем, будет соответствовать случайно сгенерированному паролю длиной в 42 бита. Другими словами, чтобы взломать пароль с 42-битной сложностью, необходимо произвести 242 попыток, исчерпав все возможные варианты методом полного перебора. Таким образом, добавление одного бита энтропии к паролю удваивает количество необходимых догадок, что делает задачу атакующего в два раза сложнее

Главное отличие ключа от пароля – в том, что пароли обычно выбираются сознательно и потому в любом случае имеют более низкую энтропию.

Слабые пароли – это пароли с особенно низкой энтропией, как-то: осмысленные слова, популярные комбинации символ или пароли, основанные на каких-то персональных данных.

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

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

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

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

58. Схемы централизованного распределения секрета. Протокол Needham–Schroeder и его реализация в протоколе Kerberos в ОС Windows.

BOOK

59. Схемы децентрализованного распределения секрета. Протокол Diffie–Hellman и задача нахождения дискретного логарифма. Пример выработки общего ключа. Атака типа «человек посередине» на алгоритм Diffie–Hellman.

Схемы децентрализованного распределения секрета – подразумевают отсутствие единого центра распространения секретных ключей. Каждые два(и более) участника могут обменяться ключом(-ами) без участия централизованного посредника и/или надежно защищенных каналов передачи данных.

Алгори́тм Ди́ффи — Хе́ллмана позволяет двум или более пользователям обменяться без посредников ключом, который может быть использован затем для симметричного шифрования. Данный алгоритм не применяется для шифрования сообщений или формирования электронной подписи. Его назначение – в распределении ключей.

При работе алгоритма, каждая сторона:

1. генерирует случайное натуральное число a(b – для второй стороны) — закрытый ключ
2. совместно с удалённой стороной устанавливает открытые параметры p и g (обычно значения p и g генерируются на одной стороне и передаются другой), где
3. p является случайным простым числом
4. g является первообразным корнем(примитивным элементом) по модулю p
5. вычисляет открытый ключ A, используя преобразование над закрытым ключом

A = g^a mod p

1. обменивается открытыми ключами с удалённой стороной
2. вычисляет общий секретный ключ K, используя открытый ключ удаленной стороны B и свой закрытый ключ a

K = B^a mod p

1. К получается равным с обеих сторон, потому что:

B^a mod p = (g^b mod p)^a mod p = g^ab mod p = (g^b mod p)^b mod p = A^b mod p

Секретность протокола базируется на не вычислимости решения задачи дискретного логарифма. А именно определения из A = g^a mod p значения a, при заданных A,g,p. Или аналогично для B = g^b mod p определение b.

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

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

В схеме разделения секрета количество долей, которые нужны для восстановления секрета, может отличаться от того, на сколько долей мы разделили секрет. Такая схема носит названия пороговой схемы (k,n), где n — количество долей, на которые был разделён секрет, а k— количество долей, которые нужны для восстановления секрета.

Схема Шамира:

Идея схемы заключается в том, что двух точек достаточно для задания прямой, трех точек — для задания параболы, четырех точек — для кубической параболы, и так далее. Чтобы задать многочлен степени требуется точек. – задача интерполяции многочлена по k+1 точкам

Если мы хотим разделить секрет таким образом, чтобы восстановить его могли только человек, мы «прячем» его в формулу -мерного многочлена. Восстановить этот многочлен можно по точкам. Количество же различных точек многочлена не ограничено (на практике оно ограничивается размером числового поля, в котором ведутся расчёты).

Пусть нужно разделить секрет между сторонами таким образом, чтобы любые участников могли бы восстановить секрет (то есть нужно реализовать -пороговую схему).

Выберем некоторое простое число p > M. Это число можно открыто сказать всем участникам. Оно задаёт конечное поле размера p. Над этим полем построим многочлен степени k − 1 (то есть случайно выберем все коэффициенты многочлена, кроме M):

В этом многочлене M — это разделяемый секрет, а остальные

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

Теперь вычисляем координаты различных n точек:

Аргументы (номера секретов) не обязательно должны идти по порядку, главное - чтобы все они были различны по модулю p.

После этого секреты (вместе с их номером, числом p и степенью многочлена k − 1) раздаются сторонам. Случайные коэффициенты и сам секрет M«забываются».

Теперь любые k участников, зная координаты k различных точек многочлена, смогут восстановить многочлен и все его коэффициенты, включая последний из них — разделённый секрет.

61. Протокол SSL (TLS) для обеспечения безопасного соединения между клиентом и сервером поверх стека протоколов TCP/IP. Протоколы рукопожатия и записи, используемые в них криптографические примитивы.

SSL/TLS

Протоколы SSL и TLS обеспечивают аутентификацию сервера и клиента и шифрование соединений. SSL был впервые введен компанией Netscape Communication в 1994 году и дважды пересматривался (последней версией SSL является версия 3). В 1996 году IETF основало рабочую группу TLS, чтобы определить протокол SSL в качестве стандарта Интернета. Протокол TLS версии 1.0 специфицирован в RFC 2246 в 1999 году и основывается на SSL версии 3. Можно считать, что SSL версии 3 и TLS версии 1 идентичны, поэтому они будут обсуждаться вместе. Протоколы TCP/IP управляют транспортом и роутингом данных в Интернете. Протоколы прикладного уровня, такие как НТТР, LDAP, IMAP, выполняются поверх TCP. SSL/TLS расположен между протоколом ТСР и протоколами прикладного уровня.

Возможности SSL/TLS

SSL/TLS обеспечивает следующие возможности.

· Аутентификация сервера – SSL/TLS позволяет web-клиенту убедиться в идентификации сервера. Поддерживающие SSL/TLS клиенты могут использовать стандартные технологии криптографии с открытым ключом для проверки имени сервера и открытого ключа, содержащихся в действительном сертификате, выпущенном СА, который перечислен в списке доверенных САs. Эта проверка может быть важна, если, например, пользователь посылает номер кредитной карты по сети и хочет иметь подтверждение идентификации получающего сервера.

· Аутентификация клиента – SSL/TLS позволяет web- серверу запрашивать идентификацию пользователя, используя ту же технологию, которая использовалась при аутентификации сервера. Поддерживающее SSL/TLS ПО web-сервера может убедиться, что сертификат клиента действительный и выпущен СА, перечисленном в списке доверенных САs. Это подтверждение может быть важным, если сервер, например, является банком и посылает конфиденциальную финансовую информацию потребителям, и при этом он хочет иметь подтверждение идентификации получателя.

· Шифрование и целостность соединения – SSL/TLS может шифровать и обеспечивать целостность информации, передаваемой между клиентом и сервером. При выборе соответствующего алгоритма шифрования SSL/TLS обеспечивает высокую степень конфиденциальности. Также обеспечивается целостность данных.

Слабые места SSL/TLS

SSL/TLS присущи некоторые ограничения. Пакеты шифруются выше уровня ТСР, таким образом, информация на уровне IP не зашифрована. Хотя это и защищает передаваемые web-данные, при просмотре соединений SSL/TLS сессии можно определить как отправителя, так и получателя с помощью незашифрованной информации IP-адреса. Кроме того, SSL/TLS защищает только передаваемые данные. Он не шифрует данные, хранимые на конечных точках. Таким образом, при хранении данные становятся уязвимыми (например, база данных кредитных карт), если не предприняты дополнительные гарантии на конечных точках.

SSL/TLS также уязвим для атаки "man-in-the-middle" при отсутствии аутентификации сервера или использовании им самоподписанного сертификата. В случае анонимного сервера общий секрет вырабатывается по алгоритму Диффи-Хеллмана, который уязвим для атак "man-in-the-middle". Аналогичная ситуация возникает, когда пользователь принимает сертификат сервера без проверки его действительности вручную или при отсутствии в браузере открытого ключа выпустившего сертификат СА.

При этом атакующий устанавливает одно множество ключей сессии для использования с настоящим сервером, и другое множество ключей – для использования с клиентом. Это позволяет атакующему не только читать все данные, которые передаются между клиентом и сервером, но и изменять данные без обнаружения этого. Следовательно, очень важно для пользователей понимать опасность данного типа атаки и проверять действительность сертификата, прежде, чем полагаться на безопасность SSL/TLS сессии. Данная угроза может быть понижена, если клиент доверяет сертификатам, выпущенным доверенными CAs, или самоподписанные сертификаты получены с использованием некоторых внешних механизмов. Предоставление самоподписанного сертификата может означать, что происходит атака "man-in-the-middle". Последние версии браузеров выполняют некоторые проверки автоматически, но на это нельзя полагаться во всех случаях.

Пример SSL/TLS-сессии

В протоколах SSL/TLS используются симметричное шифрование и криптография с открытым ключом. Симметричное шифрование быстрее, чем шифрование с открытым ключом, в то время как криптография с открытым ключом больше подходит для обеспечения аутентификации и установлении симметричных ключей. SSL/TLS сессия всегда начинается с обмена сообщениями, называемого Рукопожатием. Рукопожатие позволяет серверу аутентифицировать себя клиенту, используя криптографию с открытым ключом; это дает возможность клиенту и серверу выработать симметричные ключи. В качестве необязательной опции при Рукопожатии можно запросить аутентификацию клиента на сервере.

Основные шаги можно просуммировать следующим образом:

1. Клиент посылает номер версии, наборы криптографических алгоритмов, случайное число и другую информацию, необходимую серверу для взаимодействия с клиентом, используя SSL/TLS.

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

3. Клиент использует информацию, полученную от сервера, для аутентификации сервера. Если сервер не может быть аутентифицирован, то пользователю сообщают о проблемах и информируют, что аутентифицированное и зашифрованное соединение не может быть установлено. Если сервер успешно прошел аутентификацию, то клиент переходит к шагу 4.

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

5. Если сервер запросил аутентификацию клиента, клиент подписывает определенные данные, которые уникальны для данного Рукопожатия и известны как клиенту, так и серверу. В этом случае клиент посылает подписанные данные и свой сертификат серверу.

6. После этого сервер пытается аутентифицировать клиента. Если клиент не может быть аутентифицирован, то сессия прерывается.

7. Как клиент, так и сервер используют мастер-секрет для создания ключей сессии.

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

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

10. Теперь Рукопожатие SSL/TLS завершено и начинается SSL/TLS -сессия. Клиент и сервер используют ключи сессии для шифрования и дешифрования, а также для проверки целостности посылаемых друг другу данных.

Схемы шифрования SSL/TLS

Протокол SSL/TLS поддерживает использование различных криптографических алгоритмов для таких операций, как аутентификация сервера и клиента и установление ключей сессии.

Выбор соответствующего алгоритма шифрования зависит от нескольких факторов. Хотя на первый взгляд может показаться, что самый сильный алгоритм шифрования должен всегда указываться первым, это не всегда верно. Самый сильный алгоритм шифрования потребляет больше ресурсов сервера и снижает скорость взаимодействия. Более того, некоторые страны поддерживают ограничения на экспорт, импорт и/или использование шифрования. Проблемы с патентами и лицензиями также могут влиять на используемые схемы шифрования. Общие факторы, которые влияют на выбор алгоритма шифрования, следующие.

· Требуемая безопасность:

· Ценность данных.

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

· Возможные угрозы данным.

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

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

· Системные ресурсы. Наличие меньшего количества ресурсов (например, процессор, память) может привести к необходимости использовать более слабое шифрование.

· Ограничения экспорта и импорта.

· Схемы шифрования, поддерживаемые сервером.

· Схемы шифрования, поддерживаемые клиентом.

Требования к реализации SSL/TLS

Цифровые подписи необходимы для выполнения протокола SSL/TLS. Сертификаты могут быть выпущены третьей доверенной стороной (СА) или быть самоподписанными. Организационные требования определяют используемый подход.

Должны быть рассмотрены три ограничения на самоподписанные сертификаты.

· Браузеры могут автоматически не распознавать самоподписанный сертификат и допускать установление соединения, не предупреждая пользователя о получении самоподписанного сертификата. Следует сконфигурировать браузеры пользователей для распознавания самоподписанных сертификатов, но нужно понимать, что при этом будет возникать большое число предупреждений.

· Когда СА выпускает сертификаты, он гарантирует идентификацию организации и web- сервера. В самоподписанном сертификате web- сервер сам "гарантирует" свою идентификацию.

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

После того как сертификат получен от СА или самовыпущен, необходимо сконфигурировать SSL/TLS. Некоторые шаги, которые являются общими для всех web- серверов:

· сконфигурировать SSL/TLS для использования только криптографических алгоритмов, обеспечивающих требуемый уровень безопасности; – указать расположение сертификата сервера и других параметров, требуемых для SSL/TLS;

· сконфигурировать сервер, чтобы он слушал определенный порт (по умолчанию 443). В большинстве случаев сервер не предполагает использования SSL/TLS по умолчанию, данный порт должен быть закрыт по причинам безопасности. Необходимо сконфигурировать всю сетевую инфраструктуру для поддержки SSL/TLS трафика;

· сконфигурировать сервер для защиты необходимых ресурсов (директорий и файлов), используя SSL/TLS. При этом эти ресурсы будут доступны только по URL, начинающихся с https://.

Список действий для технологий аутентификации и шифрования

Технологии web-аутентификации и шифрования.

· Для небольшого количества web-ресурсов, которые требуют минимальной защиты и четко определенную аудиторию, следует сконфигурировать аутентификацию на основе IP-адреса.

· Для web-ресурсов, которые требуют дополнительной защиты, но которых немного, с четко определенной аудиторией, следует сконфигурировать аутентификацию на основе IP-адреса в качестве второй линии обороны.

· Для web-ресурсов, которые требуют минимальной защиты, но для которых не существует четко определенной аудитории, сконфигурировать Basic или Digest (лучше) аутентификацию.

· Для web-ресурсов, которые требуют защиты от вредоносных bots, следует сконфигурировать Basic или (лучше) Digest аутентификацию.

· Для web-ресурсов, которые требуют максимальной защиты, сконфигурировать SSL/TLS.

Конфигурирование SSL/TLS.

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

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

· Для конфигураций, которые требуют среднего уровня аутентификации клиента, следует сконфигурировать аутентификацию сервера по SSL/TLS, а запрос имени пользователя и пароля — по Basic -аутентификации или с использованием тега <form> в HTML-странице.

· Для конфигураций, которые требуют высокого уровня аутентификации клиента, сконфигурировать сервер для запроса сертификатов клиента по SSL/TLS.

· Сконфигурировать проверку целостности файла, содержащего сертификат web-сервера.

· Если используется только SSL/TLS на web-сервере, то проверить, что доступ через 80 порт запрещен.

· Если основной трафик к web-серверу будет получаться по протоколу SSL/TLS, то гарантировать, что на web-сервере используются соответствующие механизмы ведения логов и определения проникновения, потому что сетевой мониторинг не эффективен для зашифрованных сессий SSL/TLS.

№1.Приведите примеры матриц: одностолбцовой; однострочной; прямоугольной; квадратной; диагональной; единичной; симметрической; треугольных.

Дата добавления: 2015-04-24