Режимы шифрования
Олег Зензин,
Вступление
В данном материале разъясняется что такое режимы шифрования и какими они бывают. Описание пяти основных режимов шифрования приводится на основании документа, изданного Американским Национальным Институтом Стандартов и Технологий (сокращённо НИСТ). Предполагается, что читатель представляет себе, что такое блочный шифр, но не более того. То есть для понимания материала не требуется знания какого-либо блочного шифра или каких-либо других знаний по криптографии. В этом смысле материал в известной степени самодостаточен. Однако интересующимся могу порекомендовать среди прочих замечательный веб-сайт Андрея Винокурова посвящённый блочным шифрам и криптографии вообще.
Соглашения и термины
Прежде всего необходимо дать определение, что такое режим шифрования и какие в связи с этим понятия или термины нам придётся ввести. Под режимом шифрования здесь понимается такой алгоритм применения блочного шифра, который при отправке сообщения позволяет преобразовывать открытый текст в шифротекст и, после передачи этого шифротекста по открытому каналу однозначно восстановить первоначальный открытый текст. Как видно из определения сам блочный шифр теперь является лишь частью другого алгоритма – алгоритма режима шифрования. Это обусловлено тем, что блочный шифр работает только с отдельным блоком данных, в то время как алгоритм режима шифрования имеет дело уже с целым сообщением, которое может состоять из некоторого числа n блоков. Более того, сообщение вообще не обязано состоять из блоков, в том смысле, что это сообщение не всегда можно разбить на целое число n блоков. В этом случае в разных режимах шифрования приходиться дополнять сообщение различным количеством бит. Такое дополнение почти неизбежно, но минимальная величина, к которой нужно "подтянуть" длину сообщения различна для разных режимов шифрования и напрямую зависит от длины порции сообщения с которой работает каждая итерация алгоритма данного режима. Этот вопрос будет рассмотрен подробнее ниже.
Было бы удобно сразу договориться о некотрых соглашениях, которые будут здесь действовать. Поскольку преобразование данных блочным шифром учитывается здесь лишь как часть алгоритма режима шифрования, то удобно это преобразование рассматривать как функцию, которая получает на входе какие-то данные (будем называть их входнЫми данными) и после их преобразования возвращает выходнЫе данные. Когда блочный шифр применяется в режиме шифрования для зашифрования данных будем обозначать эту функцию
Далее будут рассмотрены пять режимов шифрования так, как они представлены в документе [1], изданном НИСТ США и озаглавленном "Рекомендации для режимов шифрования с блочным шифром". Это отнюдь не единственный документ изданный НИСТ касательно режимов шифрования. До этого был издан документ, описывающий четыре режима для блочного шифра DES, а также другой документ – для тройного DES (Triple DES algorithm или TDEA), в котором описано семь режимов, три из которых являются лишь вариацией на тему тех же режимов, что были описаны для DES. Основным достоинством последнего изданного документа [1] является во-первых то, что его рекомендации относятся к любому, одобренному НИСТ блочному шифру, и во-вторых в нём описан ещё один режим шифрования – пятый. Вот эти режимы:
ECB (Electronic Code Book) – електронная кодовая книга
CBC (Cipher Block Chaining) – сцепление блоков по шифротексту
CFB (Cipher Feed Back) – обратная загрузка шифротекста
OFB (Output Feed Back) – обратная загрузка выходных данных.
CTR (Counter) – шифрование со счётчиком
Электронная кодовая книга
Данный режим является электронным аналогом режима, использовавшегося агентами для отправки зашифрованного сообщения ещё в начале XX века. Агент получал блокнот, каждая страница которого содержала уникальную последовательность – код с помощью которого и зашифровывалось сообщение. После использования такая страница вырывалась из блокнота и уничтожалась. При необходимости сообщение дополнялось так, чтоб на вырываемых страничках не оставалось не использованного кода. Принимающая сторона имела копию блокнота, поэтому, при условии синхронного использования страниц такой режим шифрования обеспечивал как зашифрование так и расшифрование сообщений. В ECB использованию одной страницы кодовой книги при зашифровании соответствует применение к входным данным преобразования функцией
Рис. 1. Режим шифрования електронная кодовая книга – ECB.
Как видно из рисунка весь алгоритм ECB состоит в применении напрямую функций
ECB зашифрование:
ECB расшифрование:
В уравнениях приняты следующие обозначения:
Pj
– очередной, j-ый блок открытого текста (на рисунке – PLAINTEXT).
Cj
– очередной, j-ый блок шифротекста (на рисунке – CIPHERTEXT).
Таким образом шифрование происходит блоками, соответствующими размеру входных/выходных данных для функций
Сцепление блоков по шифротексту
В режиме шифрования CBC происходит "сцепливание" всех блоков сообщения по шифротексту. Как это достигается – видно из рисунка 2, иллюстрирующего этот режим шифрования.
Как видно из рисунка в алгоритме шифрования на вход функции
CBC зашифрование:
CBC зашифрование:
В уравнениях приняты следующие обозначения:
IV
– вектор инициализации (на рисунке – Initialization Vector);
Pj
– очередной, j-ый блок открытого текста.
Cj
– очередной, j-ый блок шифротекста.
Поскольку, как наглядно следует из рисунка, в режиме CBC при зашифровании каждая итерация алгоритма зависит от результата предыдущей итерации, то зашифрование сообщения не поддаётся расспараллеливанию. Однако в режиме расшифрования, когда весь шифротекст уже получен, функции
Обратная загрузка шифротекста
В алгоритме режима обратной загрузки шифротектса очередной блок открытого текста суммируется по модулю с блоком предыдущего шифротекста, но только после того, как этот шифротекст подвергнется дополнительной обработке функцией
В поточных режимах шифрования можно применить трюк, позволяющий сгладить проблему дополнения последнего блока сообщения. Вместо того, чтобы скармливать алгоритму режима на каждой его итерации сообщение полными блоками, текст подаётся порциями длиной
Таким образом, длина всего сообщения теперь должна быть кратна не b а s, что означает меньшее количество бит необходимое для выравнивания сообщения. Варьируя величину s можно изменять скорость работы прогаммы, реализующей режим шифрования CFB. Например, если известно, что пропускная способность канала передачи данных ограничена (или программа выдаёт текст сообщения для зашифрования с определённой скоростью), тогда, с учётом этих ограничений, можно подобрать такое значение s, что пропускная способность канала будет использоваться наиболее эффективно (либо текст сообщения будет обрабатываться с оптимальной скоростью). Но за всё приходиться платить – и теперь, поскольку за одну итерацию алгоритма шифрования преобразуется меньшее число бит, то таких итераций потребуется больше. Отношение
Уравнения режима шифрования CFB приведены ниже:
CFB зашифрование:
-----------------------------------------------------
CFB расшифрование:
В уравнениях приняты следующие обозначения:
IV
– вектор инициализации;
Pj
– очередной, j-ый блок открытого текста.
Cj
– очередной, j-ый блок шифротекста.
LSBm (
X) - m младших бит (less significant bits) двоичного числа X
MSBm (
X) - m старших бит (most significant bits) двоичного числа X
X
| Y – конкатенция битовых строк, представленных числами X и Y,
напр. 01 | 1011 = 011011
В режиме CFB при зашифровании входные данные для функции
Обратная загрузка выходных данных
Режим OFB, как и CFB является поточным, то есть функция
Ниже приведены уравнения для за- и расшифрования в режиме OFB:
OFB зашифрование:
-----------------------------------------------------
OFB расшифрование:
В уравнениях приняты следующие обозначения:
IV
– вектор инициализации;
Pj
– очередной, j-ый блок открытого текста.
Cj
– очередной, j-ый блок шифротекста.
MSBr (
X) - r старших бит (most significant bits) двоичного числа X
Как можно заметить из уравнений – проблема дополнения сообщения для OFB решается просто: её для этого режима просто не существует. Для последнего, возможно неполного, блока сообщения используется ровно столько бит выходных данных функции
Шифрование со счётчиком
В потоковом режиме шифрования со счётчиком на каждой итерации алгоритма шифрования на вход функции
Таким образом шифротекст в алгоритме режима CTR получается суммированием по модулю 2 очередного блока открытого текста с выходными данными функции
CTR зашифрование:
---------------------------------------------------
CTR расшифрование:
В уравнениях приняты следующие обозначения:
Pj
– очередной, j-ый блок открытого текста.
Cj
– очередной, j-ый блок шифротекста.
MSBr (
X) - r старших бит ( most significant bits) двоичного числа X
Режим CTR обладает всеми достоинствами режима ECB (параллельное исполнение, простота и возможность непосредственного за- и расшифрования любого блока сообщения по отдельности и независимо от других блоков). Но кроме того, режим CTR исправляет все недостатки шифрования в режиме электронной кодовой книги: одинаковые блоки открытого текста теперь уже не будут преобразованы в одинаковые блоки шифротекста; отпадает необходимость дополнения последнего блока шифротекста. К тому же в этом режиме (как в любом поточном режиме) используется только функция зашифрования
Вектор инициализации
В таких режимах шифрования, как CBC, CFB и OFB на вход функций
Непредсказуемости
В режиме OFB вектор инициализации не обязан быть непредсказуемым, зато он должен быть уникален для всех сеансов связи в которых в OFB используется один и тот же секретный ключ шифрования K. Этого можно достичь опять же используя счётчик сообщений. Если же не следовать этому требованию, то секретность сообщения в режиме OFB может быть легко скомпрометирована. Пример приведён выше при описании самого режима OFB. Одним из следствий этого требования является то, что очередной вектор инициализации для режима OFB нельзя генерировать путём применения функции
Накопление ошибок в различных режимах шифрования
Прежде всего – что такое ошибка. Ошибкой в бите данных будем называть подмену бита со значением "1" на бит "0" и наоборот. Далее обсудим как такая ошибка может повлиять на результат применения алгоритма шифрования в различных режимах, когда она возникает в шифротексте, векторе инициализации или значении счётчика Tj в режиме CTR.
В любом режиме ошибка в пределах блока (или порции – для CFB) шифротекста ведёт к неправильному расшифрованию этого блока. Так, в режимах CFB, OFB и CTR ошибочным на выходе будет тот же бит, остальные биты останутся невредимыми. В режимах же ECB и CBC повреждённым, в зависимости от силы преобразования используемого блочного шифра, может стать любой бит с вероятностью повреждения
В режимах ECB, OFB и CTR ошибка в бите отдельного блока шифротекста на повлияет на другие блоки при расшифровании. В режиме CBC такая ошибка приведёт к ошибке в том же бите при расшифровании следующего блока сообщения. Остальных блоков эта ошибка не коснётся. Другое дело режим CFB: здесь ошибка в одном бите порции шифротекста распространится на
В режиме CTR ошибка в бите счётчика Tj приведёт к возможности изменения любого бита соответствующего блока шифротекста с вероятностью
Ошибка в бите вектора инициализации также повлияет на результаты расшифрования. Так, в режиме OFB ошибка в одном бите вектора инициализации при расшифровании приведёт к полностью неверным результатам. В режиме же CFB эта ошибка при расшифровании заденет как минимум первую порцию сообщения, а как максимум
Таблица отражает эффект распространения ошибки во всех пяти режимах шифрования.
Эффект распространения ошибки
ООБ при расшифровании блока
ОЛБ при расшифровании блоков
В таблице приняты следующие сокращения:
ОЛБ – ошибка в любом бите, то есть повреждённым при расшифровании с вероятностью
ООБ – ошибка в одном бите, то есть при расшифровании повреждается один бит, находящийся в той же позиции, что и бит вызвавший ошибку.
Вставка или удаление одного бита в блок (или порцию) шифротекста нарушает синхронизацию за- и расшифрования, что приводит к возможности появления ошибок при расшифровании во всех битах, начиная с ошибочного. Только в режиме CFB с размером порции сообщения обрабатываемой за одну итерацию алгоритма в 1 бит синхронизация восстановиться автоматически через
Список использованной литературы
Recommendation for Block Cipher Modes of Operation. NIST Special Publication 800-38A. Technology Administration U.S.Department of Commerce. 2001 Edition
Защита информации в компьютерных системах и сетях. Под ред. В.Ф.Шаньгина.-М.:Радио и связь, 1999.-328с.
Communication theory of secrecy systems. C.E.Shennon.Bell System Technical Journal, vol.28, 1949.
Страничка классических блочных шифров. А.Винокуров.
Введение в криптографию. Под общ. ред. В.В.Ященко.-M.: МЦНМО: "ЧеРо", 2000.
Симметричная (секретная) методология
В этой методологии и для шифрования, и для расшифровки отправителем и получателем применяется один и тот же ключ, об использовании которого они договорились до начала взаимодействия. Если ключ не был скомпрометирован, то при расшифровке автоматически выполняется аутентификация отправителя, так как только отправитель имеет ключ, с помощью которого можно зашифровать информацию, и только получатель имеет ключ, с помощью которого можно расшифровать информацию. Так как отправитель и получатель - единственные люди, которые знают этот симметричный ключ, при компрометации ключа будет скомпрометировано только взаимодействие этих двух пользователей. Проблемой, которая будет актуальна и для других криптосистем, является вопрос о том, как безопасно распространять симметричные (секретные) ключи.
Алгоритмы симметричного шифрования используют ключи не очень большой длины и могут быстро шифровать большие объемы данных.
Порядок использования систем с симметричными ключами:
Безопасно создается, распространяется и сохраняется симметричный секретный ключ. Отправитель создает электронную подпись с помощью расчета хэш-функции для текста и присоединения полученной строки к тексту Отправитель использует быстрый симметричный алгоритм шифрования-расшифровки вместе с секретным симметричным ключом к полученному пакету (тексту вместе с присоединенной электронной подписью) для получения зашифрованного текста. Неявно таким образом производится аутентификация, так как только отправитель знает симметричный секретный ключ и может зашифровать этот пакет. Только получатель знает симметричный секретный ключ и может расшифровать этот пакет. Отправитель передает зашифрованный текст. Симметричный секретный ключ никогда не передается по незащищенным каналам связи. Получатель использует тот же самый симметричный алгоритм шифрования-расшифровки вместе с тем же самым симметричным ключом (который уже есть у получателя) к зашифрованному тексту для восстановления исходного текста и электронной подписи. Его успешное восстановление аутентифицирует кого-то, кто знает секретный ключ. Получатель отделяет электронную подпись от текста. Получатель создает другую электронную подпись с помощью расчета хэш-функции для полученного текста. Получатель сравнивает две этих электронных подписи для проверки целостности сообщения (отсутствия его искажения)
Доступными сегодня средствами, в которых используется симметричная методология, являются:
Kerberos, который был разработан для аутентификации доступа к ресурсам в сети, а не для верификации данных. Он использует центральную базу данных, в которой хранятся копии секретных ключей всех пользователей. Сети банкоматов (ATM Banking Networks). Эти системы являются оригинальными разработками владеющих ими банков и не продаются. В них также используются симметричные методологии.
Асимметричная (открытая) методология
В этой методологии ключи для шифрования и расшифровки разные, хотя и создаются вместе. Один ключ делается известным всем, а другой держится в тайне. Хотя можно шифровать и расшифровывать обоими ключами, данные, зашифрованные одним ключом, могут быть расшифрованы только другим ключом.
Все асимметричные криптосистемы являются объектом атак путем прямого перебора ключей, и поэтому в них должны использоваться гораздо более длинные ключи, чем те, которые используются в симметричных криптосистемах, для обеспечения эквивалентного уровня защиты. Это сразу же сказывается на вычислительных ресурсах, требуемых для шифрования, хотя алгоритмы шифрования на эллиптических кривых могут смягчить эту проблему. Брюс Шнейер в книге "Прикладная криптография: протоколы, алгоритмы и исходный текст на C" приводит следующие данные об эквивалентных длинах ключей.
| Длина симметричного ключа | Длина открытого ключа |
| 56 бит | 384 бит |
| 64 бита | 512 бит |
| 80 бит | 768 бит |
| 112 бит | 1792 бита |
| 128 бит | 2304 бита |
Для того чтобы избежать низкой скорости алгоритмов асимметричного шифрования, генерируется временный симметричный ключ для каждого сообщения и только он шифруется асимметричными алгоритмами. Само сообщение шифруется с использованием этого временного сеансового ключа и алгоритма шифрования/расшифровки, описанного в пункте 2.1.1.1. Затем этот сеансовый ключ шифруется с помощью открытого асимметричного ключа получателя и асимметричного алгоритма шифрования. После этого этот зашифрованный сеансовый ключ вместе с зашифрованным сообщением передается получателю. Получатель использует тот же самый асимметричный алгоритм шифрования и свой секретный ключ для расшифровки сеансового ключа, а полученный сеансовый ключ используется для расшифровки самого сообщения.
В асимметричных криптосистемах важно, чтобы сеансовые и асимметричные ключи были сопоставимы в отношении уровня безопасности, который они обеспечивают. Если используется короткий сеансовый ключ ( например, 40-битовый DES), то не имеет значения, насколько велики асимметричные ключи. Хакеры будут атаковать не их, а сеансовые ключи. Асимметричные открытые ключи уязвимы к атакам прямым перебором отчасти из-за того, что их тяжело заменить. Если атакующий узнает секретный асимметричный ключ, то будет скомпрометирован не только текущее, но и все последующие взаимодействия между отправителем и получателем.
Порядок использования систем с асимметричными ключами:
Безопасно создаются и распространяются асимметричные открытые и секретные ключи (см. раздел 2.2 ниже). Секретный асимметричный ключ передается его владельцу. Открытый асимметричный ключ хранится в базе данных X.500 и администрируется центром выдачи сертификатов (по-английски - Certification Authority или CA). Подразумевается, что пользователи должны верить, что в такой системе производится безопасное создание, распределение и администрирование ключами. Более того, если создатель ключей и лицо или система, администрирующие их, не одно и то же, то конечный пользователь должен верить, что создатель ключей на самом деле уничтожил их копию. Создается электронная подпись текста с помощью вычисления его хэш-функции. Полученное значение шифруется с использованием асимметричного секретного ключа отправителя, а затем полученная строка символов добавляется к передаваемому тексту (только отправитель может создать электронную подпись). Создается секретный симметричный ключ, который будет использоваться для шифрования только этого сообщения или сеанса взаимодействия (сеансовый ключ), затем при помощи симметричного алгоритма шифрования/расшифровки и этого ключа шифруется исходный текст вместе с добавленной к нему электронной подписью - получается зашифрованный текст (шифр-текст). Теперь нужно решить проблему с передачей сеансового ключа получателю сообщения. Отправитель должен иметь асимметричный открытый ключ центра выдачи сертификатов (CA). Перехват незашифрованных запросов на получение этого открытого ключа является распространенной формой атаки. Может существовать целая система сертификатов, подтверждающих подлинность открытого ключа CA. Стандарт X.509 описывает ряд методов для получения пользователями открытых ключей CA, но ни один из них не может полностью защитить от подмены открытого ключа CA, что наглядно доказывает, что нет такой системы, в которой можно было бы гарантировать подлинность открытого ключа CA. Отправитель запрашивает у CA асимметричный открытый ключ получателя сообщения. Этот процесс уязвим к атаке, в ходе которой атакующий вмешивается во взаимодействие между отправителем и получателем и может модифицировать трафик, передаваемый между ними. Поэтому открытый асимметричный ключ получателя "подписывается" CA. Это означает, что CA использовал свой асимметричный секретный ключ для шифрования асимметричного отркытого ключа получателя. Только CA знает асимметричный секретный ключ CA, поэтому есть гарантии того, что открытый асимметричный ключ получателя получен именно от CA. После получения асимметричный открытый ключ получателя расшифровывается с помощью асимметричного открытого ключа CA и алгоритма асимметричного шифрования/расшифровки. Естественно, предполагается, что CA не был скомпрометирован. Если же он оказывается скомпрометированным, то это выводит из строя всю сеть его пользователей. Поэтому можно и самому зашифровать открытые ключи других пользователей, но где уверенность в том, что они не скомпрометированы? Теперь шифруется сеансовый ключ с использованием асимметричного алгоритма шифрования-расшифровки и асимметричного ключа получателя (полученного от CA и расшифрованного). Зашифрованный сеансовый ключ присоединяется к зашифрованному тексту (который включает в себя также добавленную ранее электронную подпись). Весь полученный пакет данных (зашифрованный текст, в который входит помимо исходного текста его электронная подпись, и зашифрованный сеансовый ключ) передается получателю. Так как зашифрованный сеансовый ключ передается по незащищенной сети, он является очевидным объектом различных атак. Получатель выделяет зашифрованный сеансовый ключ из полученного пакета. Теперь получателю нужно решить проблему с расшифровкой сеансового ключа. Получатель должен иметь асимметричный открытый ключ центра выдачи сертификатов (CA). Используя свой секретный асимметричный ключ и тот же самый асимметричный алгоритм шифрования получатель расшифровывает сеансовый ключ. Получатель применяет тот же самый симметричный алгоритм шифрования-расшифровки и расшифрованный симметричный (сеансовый) ключ к зашифрованному тексту и получает исходный текст вместе с электронной подписью. Получатель отделяет электронную подпись от исходного текста. Получатель запрашивает у CA асимметричный открытый ключ отправителя. Как только этот ключ получен, получатель расшифровывает его с помощью открытого ключа CA и соответствующего асимметричного алгоритма шифрования-расшифровки. Затем расшифровывается хэш-функция текста с использованием открытого ключа отправителя и асимметричного алгоритма шифрования-расшифровки. Повторно вычисляется хэш-функция полученного исходного текста. Две эти хэш-функции сравниваются для проверки того, что текст не был изменен.
Алгоритм обмена ключами
Как отмечено выше, алгоритм обмена ключами KEA разработан специалистамиАНБ и используется для организации распределения ключей шифрования MEKпри информационном обмене и для рассылки секретных ключей пользователям.Основным достоинством KEA является тот факт, что обе стороны могут вычислитьодин и тот же TEK самостоятельно, используя два случайных числа (A и B),собственные параметры P, Q, G и открытый ключ абонента. Когда KEA используетсяпри информационном обмене, принимающая сторона может получить все значения,необходимые для расшифрования сообщения, вместе с принятым сообщением.
Рис. 3.
Основные функции алгоритма KEA показаны на Рис.3. Заметим, что в данномалгоритме значения P, Q и G, используемые Алисой для первоначальной генерацииTEK, а Бобом для генерации TEK при получении сообщения, не передаются поканалам связи и одинаковы для всех пользователей.
Алгоритм обмена ключами KEA применим как в приложениях типа электроннойпочты, так и при информационном обмене между абонентами, логически и/илифизически соединенными между собой в режиме реального времени.
Необходимо заметить, что одно и то же сообщение, адресованное разнымабонентам, зашифровывается с использованием одного ключа MEK, однако этотключ должен быть свернут с помощью различных TEK, соответствующих получателямданного сообщения. Приложение - адресат должно просмотреть сообщение инайти TEK, предназначенный для данного пользователя, развернуть MEK и расшифроватьполученное сообщение.
Алгоритмы шифрования
Алгоритмы шифрования с использованием ключей предполагают, что данные не сможет прочитать никто, кто не обладает ключом для их расшифровки. Они могут быть разделены на два класса, в зависимости от того, какая методология криптосистем напрямую поддерживается ими.
Асимметричные алгоритмы
Асимметричные алгоритмы используются в асимметричных криптосистемах для шифрования симметричных сеансовых ключей (которые используются для шифрования самих данных).
Используется два разных ключа - один известен всем, а другой держится в тайне. Обычно для шифрования и расшифровки используется оба этих ключа. Но данные, зашифрованные одним ключом, можно расшифровать только с помощью другого ключа.
| Тип | Описание | |
| RSA | Популярный алгоритм асимметричного шифрования, стойкость которого зависит от сложности факторизации больших целых чисел. | |
| ECC (криптосистема на основе эллиптических кривых) | Использует алгебраическую систему, которая описывается в терминах точек эллиптических кривых, для реализации асимметричного алгоритма шифрования.
Является конкурентом по отношению к другим асимметричным алгоритмам шифрования, так как при эквивалентной стойкости использует ключи меньшей длины и имеет большую производительность. Современные его реализации показывают, что эта система гораздо более эффективна, чем другие системы с открытыми ключами. Его производительность приблизительно на порядок выше, чем производительность RSA, Диффи-Хеллмана и DSA. | |
| Эль-Гамаль. | Вариант Диффи-Хеллмана, который может быть использован как для шифрования, так и для электронной подписи. |
Атаки на алгоритмы
Многие разработчики, несмотря на наличие в России государственных стандартов цифровой подписи и хэш-функции, пытаются разработать свои собственные алгоритмы. Однако, из-за низкой квалификации авторов данные алгоритмы не обладают свойствами, присущими качественным алгоритмам, разработанными математиками-криптографами. К ошибкам, которые существуют в алгоритмах криптографов-самоучек, можно отнести:
Периодическое повторение одних и тех же значений алгоритмами генерации случайных чисел, которые получили широкое распространение в криптографии. Возможность генерации одинаковой хэш-функции для двух различных документов. Такое событие называется "коллизией" и надежный алгоритм хэш-функции должен противостоять такого рода "неприятностям". Многие разработчики пытаются сохранить разработанный алгоритм в секрете, тем самым надеясь гарантировать его надежность. Однако согласно приведенному выше правилу Киркхоффа, надежность цифровой подписи должна определяться только секретностью ключа, используемого для подписи сообщения.
Кроме того, иногда в российских журналах или телеконференциях в сети Internet и FIDOnet можно прочитать сообщения об оптимизации существующих стандартов (например, ГОСТ 28147-89 или DES), которые якобы не снижают надежности самих стандартов, а скорость работы при этом возрастает на один-два порядка. К таким сообщениям надо относиться с определенной степенью скептицизма. Выгоды от применения "оптимизированных" алгоритмов сомнительны, а вот вероятность фальсификации документов, подписанных с их помощью, увеличивается.
Атаки на аппаратное обеспечение.
Некоторые системы, в особенности, коммерческие, в вопросах безопасности полагаются на защищённое от несанкционированного доступа аппаратное обеспечение – карточки с микропроцессором (smart card), электронные бумажники, защитные заглушки и т.д. Эти системы могут предполагать, что общедоступные терминальные устройства никогда не попадут не в те руки или "не те руки" не будут обладать достаточными знаниями или оборудованием для атаки на аппаратное обеспечение. Хотя аппаратное обеспечение безопасности и является важным компонентом многих надёжных систем, мы не доверяем системам, надёжность которых базируется исключительно на предположениях о защищённости от несанкционированного доступа. Нам редко встречались работоспособные системы защиты от несанкционированного доступа, а инструменты преодоления такой защиты совершенствуются постоянно. Когда мы разрабатываем системы, использующие элементы защиты от несанкционированного доступа, мы обязательно встраиваем дополнительные механизмы обеспечения безопасности на случай, если система защиты от несанкционированного доступа не сработает.
Хронометрические атаки (timing attack) наделали много шума в прессе в 1995 году: закрытые ключи RSA могут быть восстановлены измерением относительных интервалов времени, затраченных на произведение криптографических операций. Эти атаки были успешно применены к карточкам с микропроцессорами и другим средствам надёжной идентификации, а также к серверам электронной коммерции в Сети. Counterpane, в числе других, обобщила эти методы, включая атаки на системы путём измерения уровня потребления энергии, излучения и других побочных каналов и применила их против многих алгоритмов, как с открытым ключом, так и симметричных, в "надёжных" системах идентификации. Однако мы нашли средства идентификации, вытянуть из которых секретный ключ, наблюдая за побочными каналами, нам не удалось. Связанное с этим направление исследований рассматривало анализ ошибок: преднамеренно спровоцированные ошибки криптографического процессора с целью определения секретных ключей. Эффект от таких атак может быть огромным.
Атаки на цифровую подпись
Пользователю системы электронной цифровой подписи необходимо знать, каким образом злоумышленник может осуществить атаку на ЭЦП. В документации на многие системы цифровой подписи очень часто упоминается число операций, которые надо осуществить для перебора всех возможных ключей. Однако это только один из возможных вариантов реализации атак. Квалифицированный злоумышленник далеко не всегда использует такой "грубый" перебор (brute force search) всех возможных ключей. Рассмотрим подробнее некоторые из типов атак.
Атаки на криптографические модели.
Криптографическая система может быть сильна лишь настолько, насколько таковыми являются алгоритмы шифрования, алгоритмы цифровой подписи, односторонние хэш-функции и коды идентификации сообщений, на которые она опирается. Взломайте что-нибудь одно и вы взломаете систему. И как можно построить слабую структуру из крепких материалов, так и возможно построить слабую криптографическую систему из надежных алгоритмов и протоколов.
Мы часто находим системы, которые "аннулируют гарантию" своей криптографии неправильным использованием последней: не проверяя размеры значений, повторно используя случайные параметры, которые повторно использовать никогда нельзя, и т.д. Алгоритмы шифрования не всегда обеспечивают целостность данных. Протоколы обмена ключами не гарантируют получение обеими сторонами одного и того же ключа. В недавнем исследовательском проекте мы нашли, что некоторые (не все) системы, использующие связанные ключи могут быть взломаны, даже если каждый отдельный ключ безопасен. Безопасность – нечто намного большее, чем простое использование алгоритма и ожидание получить работоспособную систему. Даже хорошие инженеры, известные компании и большие усилия не гарантируют устойчивой реализации; наша работа над алгоритмом шифрования в цифровой сотовой связи в США подтвердила это.
Генераторы случайных чисел – ещё одно место, в котором часто ломаются криптографические системы. Хорошие генераторы случайных чисел сложны в разработке, так как их надёжность часто зависит от особенностей аппаратного и программного обеспечения. Многие из проверенных нами продуктов используют плохие. Криптография может быть сильной, но если генератор случайных чисел выдаёт слабые ключи, то систему взломать гораздо проще. Другие продукты используют надёжные генераторы случайных чисел, но не используют достаточно случайности для обеспечения надёжной криптографии.
Недавно Counterpane опубликовала новый класс атак на генераторы случайных чисел (), основанный на нашей работе над коммерческими моделями. Одна из самых неожиданных находок была в том, что определённые генераторы случайных чисел могут быть надёжными при использовании с одной целью, но ненадёжными для другой; обобщение анализа надёжности опасно.
В результатах другого исследования мы рассматривали взаимодействие между двумя, поодиночке надёжными криптографическими протоколами. Мы показывали, как по заданному надёжному протоколу построить другой надёжный протокол, который взломает первый при использовании с теми же ключами на том же устройстве.
Атаки на криптографию.
Порой продукты имеют изъяны в криптографической системе. Некоторые полагаются на собственные алгоритмы шифрования. Они неизменно оказываются очень слабыми. Counterpane имеет определённые достижения в области взлома известных алгоритмов шифрования, но среди "самодельных" таких достижений гораздо больше. Секретность алгоритма не является большим препятствием для анализа – в любом случае, потребуется лишь несколько дней для инженерного анализа криптографического алгоритма из исполняемого кода. Одна из проанализированных нами систем, стандарт электронной почты S/MIME 2, использовала относительно устойчивую конструкцию, но реализованную со слабым криптографическим алгоритмом. Система шифрования DVD выбрала слабый алгоритм и сделала его ещё слабее.
Мы встречали много других криптографических ошибок: реализации, повторяющие "уникальные" случайные величины, алгоритмы цифровой подписи, недостаточно тщательно проверяющие параметры, хэш-функции, изменённые так, что теряются самые важные их свойства. Мы встречали протоколы, которые использовались не так, как это было предусмотрено разработчиками и протоколы, "оптимизированные", по-видимому, тривиальными способами, что полностью лишило их надёжности.
Атаки на криптосистему
Под криптосистемой понимается не только используемый алгоритм выработки и проверки цифровой подписи, но также механизм генерации и распределения ключей и ряд других важных элементов, влияющих на надежность криптосистемы. Ее надежность складывается из надежности отдельных элементов, составляющих эту криптосистему. Поэтому в некоторых случаях нет необходимости атаковать алгоритм. Достаточно попытаться атаковать один из компонентов криптосистемы. Например, механизм генерации ключей. Если датчик случайных чисел, реализованный в криптосистеме для генерации ключей, недостаточно надежен, то говорить об эффективности такой системы не приходится. Даже при наличии хорошего алгоритма ЭЦП.
Для алгоритмов, основанных на открытых ключах, например, RSA или Эль-Гамаля, существует ряд математических проблем, которые не всегда учитываются при построении криптосистемы. К таким моментам можно отнести выбор начальных значений, на основе которых создаются ключи. Есть определенные числа, которые позволяют очень быстро вычислить секретный ключ ЭЦП. В то же время правильный выбор начальных значений позволяет гарантировать невозможность "лобовой" атаки в течение нескольких сотен лет при современном развитии вычислительной техники.
Атаки на модели доверия.
Многие из более интересных наших атак были направлены на модели доверия, лежащие в основе системы: кому или чему доверяет системы, каким образом и до какой степени. Простые системы, такие как программы шифрования содержимого жёстких дисков или продукты для обеспечения секретности телефонных переговоров, обладают простыми моделями доверия. Сложные системы, такие как системы электронной коммерции и многопользовательские системы безопасности электронной почты, имеют сложные (и тонкие) модели доверия. Программа для работы с электронной почтой может использовать невзламываемое шифрование, но пока ключи не подтверждены достоверным источником (или пока такое подтверждение не может быть проверено), система остаётся уязвимой. Некоторые коммерческие системы могут быть взломаны путём сговора продавца и покупателя, или двух разных покупателей. Другие системы делают неявные предположения о инфраструктуре обеспечения безопасности, не заботясь о проверке подлинности этих предположений. Если модель доверия не документирована, инженер может неосознанно изменить её на стадии разработки продукта и, тем самым, скомпрометировать систему обеспечения безопасности.
Многие программные системы делают неверные предположения относительно компьютеров, на которых они запущены, – они предполагают, что компьютер надёжен. Такие программы часто могут быть взломаны "троянскими конями" - программами, которые подсматривают пароли, читают открытые сообщения или обходят систему безопасности иным путём. Системы, работающие через вычислительную сеть, должны предусматривать дефекты систем безопасности, вызываемые сетевыми протоколами. Компьютеры, подключённые к Internet также уязвимы. Криптография может оказаться неуместной, если её можно обойти, воспользовавшись ненадёжностью сети. И не существует программного обеспечения, устойчивого к декомпиляции.
Часто система разрабатывается с расчётом на одну модель доверия, а реализуется с другой. Решения, принятые в процессе разработки могут быть полностью проигнорированы к моменту продажи конечному потребителю. Система, надёжная в случае использования надёжными операторами на компьютерах, находящихся под полным контролем компании, использующей систему, может оказаться ненадёжной, если операторы – временные работники с предельно низким жалованьем, а компьютеры не заслуживают доверия. Хорошие модели доверия работают даже тогда, когда одно из предположений о доверии перестаёт быть верным.
Атаки на пароли.
Многие системы взламываются из-за того, что полагаются на пароли, созданные пользователями. Предоставленные сами себе, люди не склонны к выбору надёжных паролей. Если заставить их использовать надёжные пароли, то они будут их забывать. Когда пароль становится ключом, то, обычно, проще и быстрее угадать пароль, нежели подобрать ключ – мы встречали доскональные системы, терпевшие на этом пути неудачу. Некоторые интерфейсы пользователя только усугубляют проблему, ограничивая длину пароля восемью символами, преобразовывая всё к нижнему регистру и т.д. Даже идентификационная фраза (многословный вариант пароля) может оказаться ненадёжной: поиск среди фраз из 40 символов обычно гораздо проще поиска среди произвольных ключей длиной 64 бита. Нам также встречались системы восстановления ключей, которые дискредитировали надёжные сеансовые ключи использованием слабых паролей для восстановления ключа.
Атаки на пользователей
Не стоит забывать, что конечный пользователь также является элементом криптосистемы и также подвержен атакам, наравне со всеми остальными элементами. Пользователь может передать дискету с секретным ключом ЭЦП своему коллеге для подписи документов в свое отсутствие. Пользователь может потерять такую дискету или другой носитель секретных ключей и не сообщать об утере до того момента, пока эта дискета не понадобится вновь.
Во многих системах пользователь может сам создавать себе ключи для выработки подписи. Генерация ключа основывается на паролях, выбираемых самим пользователем. Как известно фантазия в выборе таких паролей у пользователя очень слаба. Поэтому выбираются легко запоминаемые слова или фразы, которые легко угадываются злоумышленниками.
Даже если система надёжна при надлежащем обращении, пользователи могут случайно нарушить систему безопасности, особенно, если система спроектирована не очень хорошо. Классический пример – пользователь, дающий свой пароль другим сотрудникам, чтобы они могли решать какие-то вопросы, когда его самого нет на месте. Пользователи могут не докладывать о пропаже карточки доступа, если она потерялась. Они могут невнимательно проверять имя на электронном сертификате. Они могут повторно использовать свои надёжные пароли на других, ненадёжных системах. Они могут не изменить настройки безопасности программного обеспечения, установленные по умолчанию на низкий уровень безопасности. Хорошо спроектированная система не сможет решить всех этих социальных проблем, но поможет избежать многих из них.
Атаки на реализации.
Многие системы рушились из-за ошибок в реализации. Некоторые системы не убеждаются в уничтожении открытого текста после шифрования. Другие системы используют временные файлы, чтобы защититься от потерь данных, связанных с крахом системы, или виртуальную память, чтобы расширить объём доступной памяти; эти возможности могут случайно оставить открытый текст валяющимся на жёстком диске. В особых случаях операционная система может оставить ключи на жёстком диске. В одном из рассмотренных продуктов использовалось специальное окно для ввода пароля. Пароль оставался в памяти окна даже после его закрытия. И не важно, насколько хороша была криптография продукта, – он был взломан через интерфейс пользователя.
Другие системы терпели поражение от менее явных проблем. Иногда одни и те же данные шифровались двумя разными ключами, одним сильным и одним слабым. Другие системы использовали главные ключи и, затем, одноразовые сеансовые ключи. Мы взломали их с помощью частичной информации о разных ключах. Мы также встречали системы с неадекватными механизмами защиты главных ключей, ошибочно полагающихся на надёжность сеансовых ключей. Жизненно важно перекрыть все возможные пути изучения ключа, а не только самые очевидные.
Системы электронной коммерции часто идут на компромисс в вопросах реализации с целью обеспечения простоты использования. Здесь мы находили скрытые слабые места, появившиеся из-за того, что разработчики не продумывали тщательно влияние этих компромиссов на безопасность. Наверное, проводить согласование счетов раз в день проще, но какой вред может нанести злоумышленник за несколько часов? Возможно ли переполнение механизмов контроля, с целью скрыть личность злоумышленника? Некоторые системы хранят скомпрометированные ключи в рабочих списках (hotlists) – атака на такие списки может быть очень плодотворной. Другие системы могут быть взломаны посредством replay-атак: повторным использованием старых сообщений или их частей с целью обмана различных механизмов.
Системы, которые допускают восстановление ключей в экстренной ситуации, предоставляют ещё одно направление для атаки. Хорошие криптографические системы разрабатываются с таким расчётом, чтобы время жизни ключа было как можно короче. Восстановление ключей зачастую сводит на нет усилия по повышению надёжности, заставляя ключ существовать дольше, чем требуется. Более того, базы данных восстановления ключей являются источниками уязвимостей сами по себе и должны разрабатываться и реализовываться с учётом требований безопасности. В одном из рассмотренных продуктов дефект базы данных восстановления ключей давал преступникам возможность для мошенничества с возможностью свалить всё на законных пользователей.
Атаки на реализацию
Атаки именно этого типа наиболее часто используются злоумышленниками. Связано это с тем, что для их реализации нет необходимости обладать обширными познаниями в области математики. Достаточно быть квалифицированным программистом. Примеров неправильной реализации, приводящей к атаке на нее, можно назвать множество. Например:
Секретный ключ ЭЦП хранится на жестком диске. После завершения работы системы ЭЦП, ключ, хранящийся в оперативной памяти, не затирается. Обеспечивается безопасность сеансовых ключей и недостаточное внимание уделяется защите главных ключей. Открыт доступ к "черным спискам" скомпрометированных ключей. Отсутствует контроль целостности программы генерации или проверки ЭЦП, что позволяет злоумышленнику подделать подпись или результаты ее проверки.
В качестве примера атаки на реализации систем ЭЦП можно назвать случай, описанный в середине 90-х годов в отечественной прессе и связанный с устанавливаемой "закладкой" в широко распространенную программу PGP.
Вопросы, касающиеся атак на аппаратную реализацию, в данной публикации рассматриваться не будут в связи с тем, что в России практически нет средств, реализующих цифровую подпись на аппаратном уровне. Можно добавить, что существуют варианты атак на аппаратные элементы хранения ключей ЭЦП (таблетки Touch Memory, смарт-карты и т.п.). Такого рода атаки получили очень широкое распространение в последнее время.
Атаки на восстановление после сбоя.
Сильные системы проектируются с таким расчётом, чтобы не дать небольшим проблемам с системой безопасности стать большими. Восстановление ключа к одному файлу не должно давать злоумышленнику возможности читать все файла на жёстком диске. Хакер, разобравший смарт-карту не должен иметь возможности найти пути к взлому других смарт-карт в системе. В многопользовательской системе знание секретов одного не должно компрометировать других.
Многие системы по умолчанию находятся в небезопасном режиме. Если функция системы безопасности не работает, большинство людей просто отключают её и занимаются своими делами. Если система проверки кредитных карточек в реальном времени отключена, придётся воспользоваться менее надёжной "бумажной" системой. Аналогично, порой бывает возможно устроить атаку отката версии (version rollback attack) после того, как она была модернизирована для усовершенствования системы безопасности: требование обратной совместимости позволяет злоумышленнику вынудить использовать старый, менее надёжный протокол.
Другие системы не имеют возможности "на ходу" восстановиться после аварии. Если система безопасности взломана, то пути её исправить нет. Для систем электронной торговли, порой насчитывающих миллионы пользователей, это может оказаться чрезвычайно разрушительным. Такие системы должны быть готовы ответить на атаку и модернизировать систему безопасности, не выключая всю систему. Фраза "и компания сворачивается" - не то, что Вы хотели бы поместить в бизнес-план. Хороший проект системы учитывает действия на случай обнаружения атаки и вырабатывает пути локализации повреждения и восстановления после атаки.
Цифровая подпись
Для контроля целостности передаваемых сообщений, обеспечения подлинностии невозможности отрицания авторства технология Fortezza использует алгоритмцифровой подписи Digital Signature Algorithm (DSA) и алгоритм хешированияSecure Hash Algorithm (SHA-1), соответствующие стандарту NIST Digital SignatureStandard (DSS).
Процесс генерации цифровой подписи показан на Рис.4.
Рис.4.
После вычисления хэш-функции сообщения, 20-байтный хэш-блок преобразуетсяс помощь алгоритма DSA в цифровую подпись сообщения размером 40 байт. Необходимообратить внимание на различия в использовании параметров P, Q и G в алгоритмахраспределений ключей KEA и цифровой подписи DSA. При проверке цифровойподписи послания Алисы Боб должен иметь доступ к значениям P, Q и G Алисы.Эти параметры должны распространяться либо в заголовке сообщения, либовместе с открытым ключем Алисы. (В целях снабжения каждого пользователянабором собственных значений P, Q и G прикладная библиотека CI_Libraryимеет соответствующие функции загрузки этих значений.) Такое различие виспользовании этих параметров связано с возможностью DSA, в отличии отKEA, поддерживать информационный обмен между пользователями различных "доменов",которые могут различаться процедурами распространения и сертификации ключей.
На момент создания технологии Fortezza не существовало правительственныхили промышленных стандартов временных меток цифровой подписи. Для "привязки"сообщений ко времени их создания применяется дополнительная процедура вычисленияхэш-функции от хэш-блока сообщения и текущего времени, взятого из надежногоисточника (например, криптокарты Fortezza). Необходимо заметить, что значенияP, Q и G, используемые алгоритмом DSA при вычислении подписи с применениемвременных меток, являются общими для всех карт Fortezza и записываютсяв память производителем криптокарты. Поскольку проверка цифровой подписив случае применения временной метки связана с необходимостью синхронизацииисточников времени, вычислением времени доставки сообщения и рядом другихсложностей, использование временных меток в технологии Fortezza не являетсяобязательным.
Хэш-функции
Хэш-функции являются одним из важных элементов криптосистем на основе ключей. Их относительно легко вычислить, но почти невозможно расшифровать. Хэш-функция имеет исходные данные переменной длины и возвращает строку фиксированного размера (иногда называемую дайджестом сообщения - MD), обычно 128 бит. Хэш-функции используются для обнаружения модификации сообщения (то есть для электронной подписи).
| Тип | Описание | |
| MD2 | Самая медленная, оптимизирована для 8-битовых машин | |
| MD4 | Самая быстрая, оптимизирована для 32-битных машин
Не так давно взломана | |
| MD5 | Наиболее распространенная из семейства MD-функций.
Похожа на MD4, но средства повышения безопасности делают ее на 33% медленнее, чем MD4 Обеспечивает целостность данных Считается безопасной | |
| SHA (Secure Hash Algorithm) | Создает 160-битное значение хэш-функции из исходных данных переменного размера.
Предложена NIST и принята правительством США как стандарт Предназначена для использования в стандарте DSS |
Хэш-функция
Как показывает практика, алгоритмы с открытым ключом очень неэффективны из-за низкой скорости обработки большого объема данных. Для уменьшения времени на генерацию и проверку подписи, а также для сокращения ее размера применяется специальный механизм, называемый хэш-функцией (hash function), который является отображением подписываемого сообщения в строку фиксированной длины, много меньшей размера самого сообщения. Вместо подписи самого документа подписывается хэш-функция этого документа. Аналогичным образом проверяется подпись не самого документа, а его хэш-функции.
Хранение ключей
Согласно правилу Киркхоффа, сформулированному на рубеже 19 и 20 веков, надежность (стойкость) шифра и, как следствие, стойкость цифровой подписи, должна определяться только секретностью ключа, используемого для шифрования или подписи сообщения. Как следствие, секретные ключи никогда не должны храниться в явном виде на носителях, которые могут быть скопированы. Во многих существующих разработках этим условием пренебрегают, оставляя защиту секретных ключей на совести пользователя системы ЭЦП. В некоторых случаях, разработчики предлагают варианты хранения на носителях, которые, по их словам, трудно копируются. Например, таблетки Touch Memory, смарт-карты или бесконтактные карты Proximity. Однако в последнее время за рубежом участились случаи "удачных" атак на такие носители. Эти случаи преимущественно зафиксированы за рубежом, но российские "умельцы" ни в чем не уступают своим западным коллегам, и можно предсказать, что скоро случаи попыток "взлома" аппаратных носителей будут зафиксированы и в России.
Для повышения надежности таких схем хранения рекомендуется секретные ключи шифровать на других ключах, которые в свою очередь, могут быть тоже зашифрованы. Самый последний ключ в этой иерархии называется главным или мастер-ключом и не должен шифроваться. Однако к нему предъявляются очень жесткие требования к хранению в защищенной части компьютера или аппаратуры, реализующей функции цифровой подписи.
История создания криптокарты Fortezza
Технология "Fortezza Cryptographic Card", разработанная вАНБ США, представляет собой стандартное устройство PC-card (раньше этостандарт назывался PCMCIA), предназначенное для реализации аутентификациии шифрования в соответствии со стандартами правительства США. Карты Fortezzaприменяются в системе электронной связи Defence Message System (DMS) МОСША, в поисковой системе Intelink разведывательного сообщества правительстваСША, использующей технологии WWW, а также в других правительственных системах[5].
Работы по созданию Fortezza были начаты в 1991 году в рамках программыPre Message Security Protocol (PMSP) [6]. Перед специалистами АНБ былапоставлена задача разработать технологию защиты информации, не имеющейгрифа секретности, но являющейся служебной тайной организации. Первоначальнойцелью этого проекта являлось создание недорогого устройства, выполненногов стандарте "smart card" и обеспечивающего: целостность данных,шифрование данных, идентификацию и аутентификацию источника данных. Кромеэтого, необходимо было предусмотреть возможность совместимости с существующимистандартами (например, с протоколом распространения ключей X.509), обеспечитьработу мобильных пользователей, предоставить средства расширяемости архитектурыдля поддержки потенциально большого числа пользователей (до 4-х миллионов).Первоначальными областями применения технологии Fortezza виделись защитаэлектронной почты и другого электронного информационного обмена, осуществляемогопо открытым каналам связи, а также контроль доступа к системам и их компонентам.
За время развития технология несколько раз меняла свое название. Какуже говорилось, в 1991 году программа Fortezza называлась Pre Message SecurityProtocol, а само криптографическое устройство разрабатывалось в соответствиисо стандартом "smart card". В 1993 году название программы былоизменено на "MOSAIC", тип криптографического устройства измененна PC Card, а сама PC-карта получила название "Tessera Crypto Card".Затем, в 1994 году, программа была влита в объединенный проект АНБ и Агентстваинформационных систем МО США (DISA) Multi-Level Information Systems SecurityInitiative (MISSI). После этого название технологии было изменено на "Fortezza"и PC-карта переименована в "Fortezza Crypto Card".
Технология Fortezza обладает двумя важными свойствами, делающими возможнымее широкое распространение (если только это распространение не оказываетсяв сфере действия экспортных ограничений). Первым таким свойством является"персонализация" средств обеспечения безопасности. Каждый пользовательснабжается индивидуальным криптографическим устройством, PC-картой. ЭтаPC-карта содержит уникальную для каждого конкретного лица ключевую информациюи связанные с ней данные, а также выполняет заложенные в нее криптографическиеалгоритмы. Создатели карты Fortezza проделали большую работу по разработкесложной системы генерации, распределения и управления криптографическимиключами. Особое внимание было уделено контролю целостности данных картыи распространению требуемой криптографической и системной информации.
Вторым свойством является наличие открытого прикладного программногоинтерфейса (API). Аппаратные и программные спецификации карты разрабатывалисьс учетом требований к открытой системе. Это позволяет осуществлять простуюинтеграцию технологии Fortezza в большинство аппаратных платформ, коммуникационныхсредств, операционных систем, пакетов прикладных программ и сетевых протоколови архитектур. Кроме этого, подход Fortezza избавляет разработчиков программныхсредств от необходимости встраивать в прикладные программы сложные криптографическиеподсистемы. Достаточно воспользоваться PC-картой Fortezza, которой можноуправлять через API CI_Library [7].
Электронные подписи и временные метки
Электронная подпись позволяет проверять целостность данных, но не обеспечивает их конфиденциальность. Электронная подпись добавляется к сообщению и может шифроваться вместе с ним при необходимости сохранения данных в тайне. Добавление временных меток к электронной подписи позволяет обеспечить ограниченную форму контроля участников взаимодействия.
| Тип | Комментарии | |
| DSA (Digital Signature Authorization) | Алгоритм с использованием открытого ключа для создания электронной подписи, но не для шифрования.
Секретное создание хэш-значения и публичная проверка ее - только один человек может создать хэш-значение сообщения, но любой может проверить ее корректность. Основан на вычислительной сложности взятия логарифмов в конечных полях. | |
| RSA | Запатентованная RSA электронная подпись, которая позволяет проверить целостность сообщения и личность лица, создавшего электронную подпись.
Отправитель создает хэш-функцию сообщения, а затем шифрует ее с использованием своего секретного ключа. Получатель использует открытый ключ отправителя для расшифровки хэша, сам рассчитывает хэш для сообщения, и сравнивает эти два хэша. | |
| MAC (код аутентификации сообщения) | Электронная подпись, использующая схемы хэширования, аналогичные MD или SHA, но хэш-значение вычисляется с использованием как данных сообщения, так и секретного ключа. | |
| DTS (служба электронных временных меток) | Выдает пользователям временные метки, связанные с данными документа, криптографически стойким образом. |
Криптографические функции карты Fortezza
Алгоритм шифрования, применяемый в технологии Fortezza, известен подназванием SKIPJACK [8]. Этот алгоритм разработан специалистами АНБ и отвечаетстандарту депонирования ключей Escrowed Encryption Key Standard. SKIPJACKявляется блочным шифром с размером блока 8 байт, использующим симметричныеключи (т.е. для зашифрования и расшифрования применяется один и тот жеключ). Шифрование по алгоритму SKIPJACK в карте Fortezza осуществляетсяс помощью специализированного криптографического микропроцессора CAPSTONE,выполненного по RISC-технологии. Такие микропроцессоры выполняют те жефункции, что и микропроцессоры CLIPPER, применяемые для реализации алгоритмаSKIPJACK в устройствах голосовой (телефонной) связи. Обсуждение деталейреализации SKIPJACK не представляется возможным, т.к. этот алгоритм являетсязасекреченным.
Рис. 1.
В технологии Fortezza ключ шифрования данных называется Message EncryptionKey (MEK). В дополнении к этому ключу может использоваться также векторинициализации Initialization Vector (IV), который фактически является дополнительнымвходным параметром при шифровании данных. Стандартный режим алгоритма Fortezzaтребует обязательного использования IV всеми участниками информационногообмена. Это означает, что для расшифрования сообщения принимающая сторонадолжна либо иметь возможность сгенерировать точно такой же IV, которыйиспользовался отправляющей стороной при зашифровании сообщения, либо IVдолжен быть передан вместе с сообщением.
Алгоритм шифрования SKIPJACK имеет три режима работы: Electronic Codebook(ECB), Output Feedback (OFB) и Cipher Block Chaining (CBC). По умолчанию,алгоритм Fortezza использует режим CBC. В этом режиме все 8-байтные блокиоткрытого текста, кроме первого, используются для выполнения операции XORс блоком зашифрованного текста, полученным на предыдущем шаге работы алгоритмас использованием MEK. Вектор IV применяется для зашифрования первого блокаоткрытого текста.
На показан процесс посылки Алисой секретного сообщения Бобу.Для того, чтобы злоумышленник смог расшифровать сообщение Алисы, ему необходимознать не только MEK, но и IV. При этом, компрометация IV не столь существенна,если злоумышленник не обладает MEK.
Распределение ключей шифрования MEK основано на применении разработанногов АНБ алгоритма обмена ключами Key Exchange Algorithm (KEA), который посылаетзашифрованный MEK с каждым сообщением. Поскольку обмен ключами KEA интегрированв технологию Fortezza, ключи шифрования могут меняться от сообщения к сообщениюили от сеанса к сеансу. Алгоритм KEA использует для шифрования MEK специальныйключ, названный Token Encryption Key (TEK). Необходимо иметь в виду, чтов приложениях, использующих технологию Fortezza, TEK может быть использованпри шифровании данных как альтернатива ключа шифрования MEK, однако MEKне может быть использован для защиты TEK в процессе обмена ключами.
Рис. 2.
Шифрование с открытым ключем в стандартном режиме алгоритма Fortezzaиспользуется только для обмена ключами с использованием KEA и для цифровойподписи сообщений (включая временные метки). В описании алгоритма Fortezzaобычно используют следующие обозначения: 20-байтный закрытый ключ называется"X", 128-байтный открытый ключ называется "Y", P иQ - большие простые числа (секретные), G - простое число по модулю P*Q(общедоступное).
На представлен общий процесс шифрования сообщений с использованиемоткрытого ключа абонента. Алиса зашифровывает сообщение для Боба, используяоткрытый ключ Боба Y и алгоритм шифрования с открытым ключом. Боб расшифровываетпослание Алисы с помощью своего открытого ключа X. Каждый, кто получитдоступ к месту хранения открытых ключей, сможет зашифровать данные дляБоба, но только Боб сможет расшифровать эти данные, поскольку никто незнает его закрытого ключа. Генерация и распределение пар открытого и закрытогоключей для организации обмена ключами KEA и цифровой подписи производитсядля каждого пользователя отдельно в соответствии со специальной процедурой.
Криптография
| Sub rosa |
Информация предоставлена , сервер
Вопрос защиты переписки от несанкционированного доступа стар,
как мир, и напрямую связан с вопросом защиты нашей privacy. Люди,
эти странные существа, почему-то упорно не хотят, чтобы их письма
читали. А другие люди и правительственные учреждения многих стран
почему-то упорно желают их прочесть. Зачем нужно защищать свою
переписку от чужих глаз законопослушному гражданину, спросит автора
читатель. А за тем же, зачем вы, пользуясь обычной почтой, отправляете
обычно письма в конверте, а не почтовой открыткой.
Существует довольно много способов защиты вашей электронной почты
от чужих глаз. Автор предлагает вам выбрать подходящий, либо продолжать
сообщать всем заинтересованным лицам информацию о своих семейных,
финансовых и прочих делах. Вам решать:)
Юридические и политические аспекты использования криптографических систем в России вынесены автором на . Приглашаю резидентов РФ и всех заинтересованных людей ознакомиться с ней.
Pretty Good Privacy (PGP)
Очень сильное средство криптографической защиты. Сила PGP не в том, что
никто не знает, как ее взломать иначе как используя "лобовую атаку" (это не сила, а условие существования хорошей программы для шифровки), а в превосходно продуманном и чрезвычайно мощном механизме обработки ключей (см. ниже), быстроте, удобстве и широте распространения. Существуют десятки не менее сильных алгоритмов шифровки, чем тот, который используется в PGP, но популярность и бесплатное распространение сделали PGP фактическим стандартом для электронной переписки во всем
мире.
Обычные средства криптографии (с одним ключом для шифровки
и дешифровки) предполагали, что стороны, вступающие в переписку,
должны были в начале обменяться секретным ключом, или паролем,
если хотите, с использованием некоего секретного канала (дупло,
личная встреча etc.), для того, чтобы начать обмен зашифрованными
сообщениями. Получается замкнутый круг: чтобы передать секретный
ключ, нужен секретный канал. Чтобы создать секретный канал, нужен
ключ.
Разработанная Филипом Циммерманном программа PGP относится
к классу систем с двумя ключами, публичным и секретным. Это означает,
что вы можете сообщить о своем публичном ключе всему свету, при
этом пользователи программы смогут отправлять вам зашифрованные
сообщения, которые никто, кроме вас, расшифровать не сможет. Вы
же их расшифровываете с помощью вашего второго, секретного ключа,
который держится в тайне. Публичный ключ выглядит примерно так
:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i
mQCNAzF1IgwAAAEEANOvroJEWEq6npGLZTqssS5EScVUPVaRu4ePLiDjUz6U7aQr
Wk45dIxg0797PFNvPcMRzQZeTxYl0ftyMHL/6ZF9wcx64jyLH40tE2DOG9yqwKAn
yUDFpgRmoL3pbxXZx9lO0uuzlkAz+xU6OwGx/EBKYOKPTTtDzSL0AQxLTyGZAAUR
tClCb2IgU3dhbnNvbiA8cmpzd2FuQHNlYXR0bGUtd2Vid29ya3MuY29tPokAlQMF
EDF2lpI4h53aEsqJyQEB6JcD/RPxg6g7tfHFi0Qiaf5yaH0YGEVoxcdFyZXr/ITz
rgztNXRUi0qU2MDEmh2RoEcDsIfGVZHSRpkCg8iS+35sAz9c2S+q5vQxOsZJz72B
LZUFJ72fbC3fZZD9X9lMsJH+xxX9CDx92xm1IglMT25S0X2o/uBAd33KpEI6g6xv
-----END PGP PUBLIC KEY BLOCK-----
Вы можете опубликовать свой публичный ключ на вашей Web странице
, или послать его электронной почтой своему другу. Ваш корреспондент зашифруют сообщение с использованием
вашего публичного ключа и отправит его вам. Прочесть его сможете
только вы с использованием секретного ключа. Даже сам отправитель
не сможет расшифровать адресованное вам сообщение, хотя он сам
написал его 5 минут назад. И самое приятное. На сегодня даже самым
мощным компьтерам в требуются века, чтобы расшифровать сообщение, зашифрованное с помощью PGP!
Программа PGP широко доступна в
сети. В связи с ограничениями на экспорт криптографической продукции, действующими в США, резиденты и нерезиденты США должны использовать разные места для загрузки программы.
Резиденты США по закону должны пользоваться либо бесплатной версией 2.6.2 , которую можно загрузить с сайта , либо только что вышедшей великолепной , написанной для различных платформ. PGP 5.0 имеет ограниченный срок бесплатного пользования (2 месяца), хотя при желании это ограничение можно обойти. Читайте
, там все описано, стоит лишь ввести ключевые слова Re crack PGP 5.0 ;)
Для всех тех, кто постоянно проживает за пределами США, главный сайт расположен . Последняя легально экспортированная версия на сегодня - это версия 2.6.3i (знак i после версии означает international). Ее также можно скачать (323К). Несмотря на запрещение экспорта версии PGP 5.0, она по старой доброй традиции была немедленно проэкспортирована из США. Поскольку незаконным является только сам экспорт, но не использование программы, автор рад сообщить вам, что версию 5.0 можно спокойно скачать с европейских сайтов
или (3.5 MB).
Сам по себе экспорт PGP из США в 1991 году, распространение программы по всему миру, судебное преследование автора, юридические хитрости, недавно использованные для законного экспорта в Европу версии 5.0 в печатном виде, и другие связанные с PGP моменты представляют из себя историю весьма занимательную. Читайте об этом на официальном сайте .
Теперь практические вопросы использования PGP. В то время как PGP 5.0 представляет из себя полноценную, имеющую графический интерфейс, программу для Windows 95 и Макинтоша, пользователи, которые по той или иной причине предпочитают использовать версии 2.xx, будут иметь дело с чисто текстовой программой, весьма неудобной в использовании. Хорошая новость: для таких версий
PGP написано множество plug-ins и front ends, делающих использование
PGP в Widows 95 делом элементарным. Часть из них собрана в
директории архива , но лучшие из опробованных автором являются следующие:
(2.43M),выпускаемый . Серьезный front end со множеством функций.
(80K), очень милая программа с набором функций, способным удовлетворить подавляющее большинство пользователей. После загрузки принимает вид такого окна:
Оба продукта шифруют и дешифруют как данные из clipboard'а, так и файлы на диске.
Напоминаю, что для пользования любым из plug-ins, front ends и shells с версиями 2.xx (но не версией 5.0, она содержит все необходимые файлы!) нужен сам файл , т.к. программы-надстройки саму PGP не содержат, так что не забудьте скачать и его.
Зашифровка информации в изображении и звуке
Этот класс продуктов позволяет прятать ваши сообщения в файлы
.bmp, .gif, .wav и предназначен для тех случаев, когда вы не хотите,
чтобы у кого-либо создалось впечатление, то вы пользуетесь средствами
криптографии. Пример подобной программы -
(273К). Программой очень легко пользоваться.
Внешне графический файл остается практически неизменным, меняются
лишь кое-где оттенки цвета. Для большей безопасности следует использовать неизвестные
широкой публике изображения, изменения в которых не бросятся
в глаза с первого взгляда, а также изображения с большим количеством
полутонов и оттенков. Использовать картину Танец Матисса - идея
плохая, т.к. все знают, как она выглядит, и кроме того она содержит
большие зоны одного цвета. А вот фотография вашего песика вполне
подойдет. Pассмотрим пример:
 |
 |
Зашифровка с помощью архиватора Pkzip
Знакомое имя, не правда ли?
позволяет архивировать
файлы с защитой паролем. Синтаксис команды описан в самом файле,
если его запустить без аргументов. Этот способ защиты значительно слабее описанных выше. Специалисты по криптографии утверждают, что в методе шифрования, используемом программой pkzip, обнаружены "дыры",
позволяющих взломать архив, не только подобрав пароль, но и другими способами. Так что будьте осторожны, используйте программу только тогда, когда вы уверены, что ваш "противник" не очень силен. Если подбор пароля будет производится с помощью обычного PC с использованием распространенных программ подбора ключа, pkzip может послужить
весьма удобным и быстрым способом защиты информации, хотя и обладающим
описанным выше "семейным" недостатком всех систем криптозащиты
с одним ключом.
Программы взлома, которые можно позаимствовать (требует, чтобы защищенный
паролем архив содержал как минимум 3 файла, 46K) или (24K), используют
один из двух подходов по выбору пользователя. Они либо подбирают
пароль с использованием большого словаря, либо атакуют в лоб (brute
force), перебирая все возможные комбинации. Согласно исследованиям
психологов, большинство мужчин в качестве пароля используют короткие
слова из ненормативной лексики, а женщины - имена любимых мужчин
или детей. Так что если ваша жена использует пароль Vasya, а вас
зовут Петя, это повод задуматься;) Отсюда простой вывод: используйте
пароль, который вряд ли есть в словаре, а главное - длинный (до
24 знаков), и содержащий цифры, специальные символы (?!$ etc.).
Для лобовой атаки (подбор комбинации из всех возможных) со скоростью
200 000 комбинации в секунду (примерно соответствует возможностям
PC Pentium 100) для пароля из 6 знаков расклад таков:
| Набор символов | Максимальное время |
| только цифры | 5.0 секунд |
| только строчные буквы | 25.7 минуты |
| только символы | 1.8 часа |
| строчные и заглавные буквы | 27.5 часа |
| строчные, заглавные, цифры | 3.3 дня |
| строчные, заглавные, цифры, символы | 42.5 дня |
Защита документов MS Word паролем
Не используйте этот метод. Никогда. Взлом настолько прост, что
изготовитель коммерческого пакета для восстановления паролей,
забытых незадачливыми пользователями, включил в программу пустые
циклы, чтобы замедлить ее работу для создания впечатления сложности
поставленной задачи.
Copyright © 1997
Криптография сегодня
Криптография - это наука об обеспечении безопасности данных. Она занимается поисками решений четырех важных проблем безопасности - конфиденциальности, аутентификации, целостности и контроля участников взаимодействия. Шифрование - это преобразование данных в нечитабельную форму, используя ключи шифрования-расшифровки. Шифрование позволяет обеспечить конфиденциальность, сохраняя информацию в тайне от того, кому она не предназначена.
Криптокарта FORTEZZA - правительственные технологии в коммерческих приложениях
(обзор по материалам открытой печати)
,
Основным отличием текущей, третьей, версии протокола SSL является поддержкабольшего количества алгоритмов и аппаратных средств обмена ключевой информациейи шифрования, в том числе и технологии Fortezza, разработанной специалистамиАНБ США [2]. Поддержка криптокарты Fortezza в программных продуктах семействаNetscape была запланирована более года назад. В октябре 1995 года вице-президентNetscape Марк Андриссен (Mark Andreessen) заявил, что поддержка технологииFortezza позволит укрепить позиции компании в качестве ведущего поставщикапрограммных продуктов, использующих Web-технологии, как для федеральногоправительства США, так и для коммерческих организаций [3]. Результаты незаставили себя ждать: Netscape стала первой компанией, которой правительствоСША в июле 1996 с.г. предоставило право распространять по сети Internetпрограммное обеспечение, подлежащее экспортным ограничениям [4]. NetscapeNavigator и Netscape FastTrack Server стали первыми программными продуктами,использующими алгоритм RC4 с длиной ключа 128 бит, которые американскиепользователи могут получить по сети Internet.
В настоящее время число компаний, поддерживающих протокол SSL, значительноувеличилось. Среди них: Apple Computer, Inc., Digital Equipment Corporation,IBM, MasterCard International Inc., Microsoft Corporation, Motorola, Novell,Inc., Siemens Nixdorf, Silicon Graphics, Inc., Sun Microsystems, Inc.,Visa International и др. Существуют также и некоммерческие реализации,например WWW-сервер Apache-SSL. Широкое распространение протокола SSL делаетвозможным и необходимым более детальное ознакомление с одним из его средств- криптокартой Fortezza.
Криптосистемы
Криптосистема работает по определенной методологии (процедуре). Она состоит из : одного или более алгоритмов шифрования (математических формул); ключей, используемых этими алгоритмами шифрования; системы управления ключами; незашифрованного текста; и зашифрованного текста (шифртекста).
Согласно методологии сначала к тексту применяются алгоритм шифрования и ключ для получения из него шифртекста. Затем шифртекст передается к месту назначения, где тот же самый алгоритм используется для его расшифровки, чтобы получить снова текст. Также в методологию входят процедуры создания ключей и их распространения (не показанные на рисунке).
Литература
ГОСТ 28147-89 Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования. Мухачов В.А. Теоретико-числові методи криптографії: методичні рекомендації до самостійної роботи студентів. - К.: ДУІКТ, 2004. - 70 с. НД ТЗІ 2.3-003-2001. Технічний захист мовної інформації в симетричних абонентських аналогових телефонних лініях. Засоби активного приховування мовної інформації. Генератори спеціальних сигналів. Методика випробувань. Штейнер Б. Прикладная криптография: 2-е издание. М., 1996 - 608 с. Menezes A., P. van Oorschot, Vanstone S. HandBook of Applied Cryptography. - CRC Press, 1996, - 816 pages.
[1]. Пресс-релиз. Netscape Communications Corporation. June 17, 1996
[2]. The SSL Protocol. Version 3.0. Internet draft. March 1996.
[3]. Пресс-релиз. Netscape Communications Corporation. October 10, 1995.
[4]. Пресс-релиз. Netscape Communications Corporation. July 16, 1996.
[5]. PC Newswire. October 10, 1995.
[6].
[7].
[8]. The Cambridge Algorithms Workshop. Bruce Schneier. Dr.Dobb's Journal,April 1994.
[9].
[10].
[11].
Гольдштейн Б.С. Системы коммутации: Учебник для ВУЗов. 2-е изд. - СПб.: БХВ - Санкт-Петербург, 2004. - 314 с.
Гончарок М. Х., Крюков Ю. С. Построение системы защиты информации в цифровых АТС и выбор класса защищенности // Защита информации. Конфидент - 2004 № 2. - с. 2-7.
Корнышев Ю.Н., Романцов В.М., Стовбун Г.В. Сигнализация на телефонных сетях: Учебн. пособие / Украинская Государственная Академия связи им. А.С.Попова. Одесса, 1996. - 64 с.
НД ТЗІ 3.7-002-99. Технічний захист інформації на програмно-керованих АТС загального користування. Методика оцінки захищеності інформації (базова).
НД ТЗІ 2.3-003-2001. Технічний захист мовної інформації в симетричних абонентських аналогових телефонних лініях. Засоби активного приховування мовної інформації. Генератори спеціальних сигналів. Методика випробувань.
ТР ТЗІ - ПЕМВН-95. Тимчасові рекомендації з технічного захисту інформації від витоку каналами побічних електромагнітних випромінювань і наводок.
Механизмы аутентификации
Эти механизмы позволяют проверить подлинность личности участника взаимодействия безопасным и надежным способом.
| Тип | Описание | |
| Пароли или PIN-коды (персональные идентификационные номера) | Что-то, что знает пользователь и что также знает другой участник взаимодействия.
Обычно аутентификация производится в 2 этапа. Может организовываться обмен паролями для взаимной аутентификации. | |
| Одноразовый пароль | Пароль, который никогда больше не используется.
Часто используется постоянно меняющееся значение, которое базируется на постоянном пароле. | |
| CHAP (протокол аутентификации запрос-ответ) | Одна из сторон инициирует аутентификацию с помощью посылки уникального и непредсказуемого значения "запрос" другой стороне, а другая сторона посылает вычисленный с помощью "запроса" и секрета ответ. Так как обе стороны владеют секретом, то первая сторона может проверить правильность ответа второй стороны. | |
| Встречная проверка (Callback) | Телефонный звонок серверу и указание имени пользователя приводит к тому, что сервер затем сам звонит по номеру, который указан для этого имени пользователя в его конфигурационных данных. |
Методология с использованием ключа
В этой методологии алгоритм шифрования объединяет ключ с текстом для создания шифртекста. Безопасность систем шифрования такого типа зависит от конфиденциальности ключа, используемого в алгоритме шифрования, а не от хранения в тайне самого алгоритма. Многие алгоритмы шифрования общедоступны и были хорошо проверены благодаря этому (например, DES).
Но основная проблема, связанная с этой методологией, состоит в том, как сгенерировать и безопасно передать ключи участникам взаимодействия. Как установить безопасный канал передачи информации между участниками взаимодействия до передачи ключей?
Другой проблемой является аутентификация. При этом существуют две серьезных проблемы:
Сообщение шифруется кем-то, кто владеет ключом в данный момент. Это может быть владелец ключа; но если система скомпрометирована, это может быть другой человек. Когда участники взаимодействия получают ключи, откуда они могут узнать, что эти ключи на самом деле были созданы и посланы уполномоченным на это лицом?
Существуют две методологии с использованием ключей - симметричная (с секретным ключом) и асимметричная (с открытым ключом). Каждая методология использует свои собственные процедуры, свои способы распределения ключей, типы ключей и алгоритмы шифрования и расшифровки ключей. Так как терминология, используемая этими методологиями, может показаться непонятной, дадим определения основным терминам:
| Термин | Значение | Замечания | |
| Симметричная методология | Используется один ключ, с помощью которого производится как шифрование, так и расшифровка с использованием одного и того же алгоритма симметричного шифрования.
Этот ключ передается двум участникам взаимодействия безопасным образом до передачи зашифрованных данных. | Часто называется методологией с секретным ключом. | |
| Асимметричная методология | Использует алгоритмы симметричного шифрования и симметричные ключи для шифрования данных
Использует алгоритмы асимметричного шифрования и асимметричные ключи для шифрования симметричного ключа. Создаются два взаимосвязанных асимметричных ключа. Симметричный ключ, зашифрованный с использованием одного асимметричного ключа и алгоритма асимметричного шифрования, должен расшифровываться с использованием другого ключа и того же алгоритма шифрования. Создаются два взаимосвязанных асимметричных ключа. Один должен быть безопасно передан его владельцу, а другой - тому лицу, которое отвечает за хранение этих ключей (CA - сертификационному центру ключей), до начала их использования. | Часто называется методологией с открытым ключом | |
| Секретный ключ(1) | Симметричная методология | Используется один ключ, с помощью которого производится как шифрование, так и расшифровка. См. выше | |
| Секретный ключ(2) | Секретный ключ симметричного шифрования | Симметричный секретный ключ | |
| Секретный ключ(3) | Секретный ключ асимметричного шифрования | Асимметричный секретный ключ
Асимметричные ключи создаются парами, так как связаны друг с другом. Выражение "секретный ключ" часто используют для одного из пары асимметричных ключей, который должен держаться в секрете. Асимметричный секретный ключ не имеет ничего общего с симметричным секретным ключом. | |
| Открытый ключ (1) | Асимметричная методология | Использует пару ключей, которые совместно создаются и связаны друг с другом. Все, что зашифровано одним ключом, может быть расшифровано только другим ключом этой пары. | |
| Открытый ключ (2) | Открытый ключ асимметричного шифрования | Асимметричные ключи создаются парами, каждый из двух ключей связан с другим.
Выражение "открытый ключ" часто используют для одного из пары асимметричных ключей, который должен быть всем известен. | |
| Сеансовый ключ | Симметричный (секретный) ключ шифрования | Используется в асимметричной методологии для шифрования самих данных с помощью симметричных методологий.
Это просто симметричный секретный ключ (см. выше) | |
| Алгоритм шифрования | Математическая формула | Для симметричных алгоритмов требуются симметричные ключи.
Для асимметричных алгоритмов требуются асимметричные ключи. Вы не можете использовать симметричные ключи для асимметричных алгоритмов и наоборот. | |
| Секретные криптосистемы | Используют симметричные алгоритмы и симметричные (секретные) ключи для шифрования данных. |   | |
| Открытые криптосистемы | Использует асимметричные алгоритмы и асимметричные ключи для шифрования сеансовых ключей.
Используют симметричные алгоритмы и симметричные (секретные) ключи для шифрования данных. |   |
Методы защиты информации в канале связи
Методы защиты информации в канале связи можно разделить на две группы:
основанные на ограничении физического доступа к линии и аппаратуре связи;
основанные на преобразовании сигналов в линии к форме, исключающей (затрудняющей) для злоумышленника восприятие или искажение содержания передачи.
Методы первой группы в основном находят применение в системах правительственной связи, где осуществляется контроль доступа к среде передачи данных.
Методы второй группы направлены на обратимое изменение формы представления передаваемой информации. Преобразование должно придавать информации вид, исключающий ее восприятие при использовании аппаратуры, стандартной для данного канала связи. При использовании же специальной аппаратуры восстановление исходного вида информации должно требовать затрат времени и средств, которые по оценке владельца защищаемой информации делают бессмысленным для злоумышленника вмешательство в информационный процесс.
При защите обмена данными решающее значение имеет форма представления сигнала в канале связи.
Следует учесть, что деление на "аналоговый" или "цифровой" сигнал условно. Для некоторых вариантов механизмов защиты информации требуется взаимная синхронизация и обмен служебными посылками между взаимодействующей аппаратурой защиты, т.е. присутствует цифровой режим, однако, поскольку этот режим не связан непосредственно с речевым обменом, требования к его скоростным характеристикам достаточно свободны.
С другой стороны, символьный (цифровой) обмен в протяженных каналах всегда осуществляется через модемное преобразование в виде аналогового сигнала.
Попробуем провести краткий анализ вариантов угроз информации в канале связи. Для удобства анализа проведем классификацию канала связи по степени защищенности (защиты) передаваемой информации.
Полученные результаты сведем в таблицу 1. На рисунках 1, 2 изобразим структурные схемы передачи данных для соответствующих каналов на примере взаимодействия ОО (КСЗИ) с АТС и удаленным ОО (КСЗИ).
| Открытый канал | Защита информации основана на ограничении доступа к линии. Возможно несанкционированное подключение к линии. Возможен перехват: При использовании услуги "Междугородная связь по паролю" возможно перехватить этот пароль, так как он передается с помощью DTMF; Управляющей информации для/от АТС; Всех данных, передаваемых по каналу связи, вне зависимости от используемой технологии передачи; Управляющей информации ОО (удаленное управление ОО, сигнализацией и т.д. Особенно небезопасен перехват команд отключения для некоторых видов охранной сигнализации). Возможен перехват/модификация трафика и его полный анализ. |
| Полузакрытый канал (закрывается только информация, управляющая информация передается в открытом виде). | Защита информации основана как на ограничении доступа к линии, так и на КЗИ. Данные закрываются с использованием КСЗИ (по ГОСТ 28147-89 в любом режиме). Возможно несанкционированное подключение к линии. Возможем перехват: при использовании услуги "Междугородная связь по паролю" также возможно перехватить этот пароль (если он набирался в открытом режиме); управляющей информации для/от АТС; момента установления защищенного соединения (возможен перехват ключей); открытых данных/разговора. Возможен перехват трафика но анализ только управляющей информации и открытых данных (опять проблема перехвата команд отключения систем охранной сигнализации). |
Таблица 1. Анализ вариантов угроз информации в канале связи.
Структурная схема передачи данных в открытом канале показана на рисунке 1.
Рисунок 1. Передача данных в открытом канале данных.
Рисунок 2. Передача данных в полузакрытом канале данных.
Примечание:
А2 - алгоритм 2, К2 - ключ алгоритма А2.
Основная проблема, с которой сталкиваются пользователи сетей, где применяется сквозное шифрование, связана с тем, что служебная информация. используемая для учстановления соединения, передается по сети в незашифрованном виде. Опытный криптоаналитик может извлечь для себя массу полезной информации, зная кто с кем, как долго и в какие часы общается через сеть доступа. Для этого ему даже не потребуется быть в курсе предмета общения.
По сравнению с канальным, сквозное шифрование характеризуется более сложной работой с ключами, поскольку каждая пара пользователей должна быть снабжена одинаковыми ключами, прежде чем они смогут связаться друг с другом. А поскольку криптографический алгоритм реализуется на верхних уровнях модели OSI, приходится также сталкиваться со многими существенными различиями в коммуникационных протоколах и интерфейсах сети доступа (для примера: отправитель - канал ТЧ, получатель - 2B+D). Все это затрудняет практическое применение сквозного шифрования.
Приведенные выше методы защиты информации уже не удолетворяют современных требованиям. При использовании этих методов злоумышленник может перехватывать адресную информацию, вести мониторинг передаваемых данных, несанкционированно подключаться к линии, искажать передаваемую информацию.
Единственным возможным методом, удовлетворяющим всем современны требованиям, является использования комбинации канального и сквозного шифрования. При этом может закрывается вся передаваемая по каналу связи информация.
Комбинация канального и сквозного шифрования данных в сети доступа обходится значительно дороже, чем каждое из них по отдельности. Однако именно такой подход позволяет наилучшим образом защитить данные, передаваемые по сети. Шифрование в каждом канале связи не позволяет злоумышленнику анализировать служебную информацию, используемую для маршрутизации. А сквозное шифрование уменьшает вероятность доступа к незашифрованным данным в узлах сети.
При этом злоумышленник может проводить анализ только открыто передаваемых данных, но не может нелегально использовать линию связи.
Структурная схема передачи данных в закрытом канале показана на рисунке 3.
Кратко опишем механизм взаимодействия КСЗИ и АТС (удаленной КСЗИ) в предложенном методе.
При занятии линии (получении сигнала вызова от АТС) происходит автоматический переход в закрытый режим связи (А1, К1). После перехода в закрытый режим, абонентский комплект (АК) или криптографический модуль перед АК АТС аутентифицирует КСЗИ. Данный шаг необходим для устранения возможности несанкционированного использования линии. После проведения аутентификации возможен выход из закрытого режима.
При вызове со стороны вызывающего абонента, АТС принимает адресную информацию, устанавливает соединение.
При ответе удаленной КСЗИ возможны два варианта: аутентификации удаленной КСЗИ и переход в закрытый режим (А2, К2) либо переход в закрытый режим (А2, К2) и аутентификация удаленной КСЗИ.
Аутентификация удаленной КСЗИ необходима для противодействия атаке, при которой удаленная КСЗИ злоумышленника при помощи перекоммутации выдает себя за КСЗИ легального пользователя.
Рисунок 3. Передача данных в закрытом канале данных (закрываются все данные).
Примечание:
А1 - алгоритм 1, К1 - ключ алгоритма А1;
А2 - алгоритм 2, К2 - ключ алгоритма А2.
После удачной аутентификации удаленной КСЗИ также возможен выход из защищенного режима (отказ от вхождение в защищенный режим).
Также при передаче данных необходимо проводить т.н. проверку обратного кода. Проверка обратного кода - представляет собой процедуру защиты, осуществляемую в процессе передачи данных. Заключается в том, что у удаленной КСЗИ периодически запрашивается идентифицирующая информация, которая и называется обратным кодом. Эта информация сравнивается с эталонной, сохраненной при аутентификации в начале сеанса связи. При несовпадении кодов передача блокируется. Проверкой обратного кода можно обнаружить факт изменения (перекоммутации) направлений выдачи данных или злоумышленного использования приемного устройства зарегистрированного (законного) корреспондента.
Предъявляемые требования к взаимодействию криптоалгоритмов можно описать с помощью логического выражения:
[(А1=А2)∪(А1 А2)])∩(К1≠К2)=True
Модернизация шифра с простым вероятностным механизмом.
Copyright © Titov Oleg, 2001, .
Одним из перспективных способов повышения стойкости известных шифров является задание неопределенности хода шифрования информации. Эта идея может быть реализована путем введения случайных данных в преобразуемое сообщение. "Подмешивание" случайных данных к шифруемому сообщению позволяет задать вероятностный характер операций преобразования и тем самым повысить вычислительную стойкость криптосистемы.
Пусть E есть b-битовая функция шифрования, P есть p-битовый блок открытого текста и R - r-битовый случайный блок, где b=r+p. Подадим на вход шифрующей функции блок B = R | P , где знак "|" обозначает конкатенацию двоичных векторов R и P:
P -> B = R | P -> C = E( B, K ),
где K - ключ шифрования. Для шифрования больших объемов данных исходный текст разбивается на блоки длиной p-бит и с каждым из них проводятся вышеуказанные операции. Для каждого такого блока в простых вероятностных шифрах генерируется новый случайный вектор R. В модернизированном простом вероятностном шифре для второго и далее блоков не генерируется случайный вектор R, а случайные биты берутся из предыдущего зашифрованного блока по следующей схеме.
Пусть P=P1|P2|P3|...|Pn - преобразуемое исходное сообщение, R - случайный r-битовый вектор, тогда
B1 = R | P1 , C1' | C1 = E( B1, K ), Bi = Ci-1 | Pi , Ci' | Ci = E( Bi, K ), C=C1' | C2' | ... | Cn' | Cn
где i изменяется от 2 до n, Ci' - p-битовый вектор, Ci - r-битовый вектор.
В результате мы избавляемся от главного недостатка простых вероятностных шифров - увеличение размера зашифрованного текста в сравнении с незашифрованым в b/p раз. Переход от случайных бит к псевдослучайным, при наличии "хорошей" функции E, не является существенным недостатком, т.к. в существующих криптографических системах используются именно псевдослучайные биты.
Подпись документов при помощи криптосистем с открытыми ключами
Поиски методов, устраняющих указанные выше недостатки, велись по нескольким направлениям. Наиболее впечатляющих результатов добились криптографы-математики Уитфилд Диффи (W. Diffie) и Мартин Хеллман (M. Hellman), а также Ральф Меркль (Ralph Merkle), которые в конце 70-х годов опубликовали результаты своих исследований. В своих работах авторы показали, что существует возможность построения криптосистем, не требующих передачи секретного ключа между абонентами, участвующими в обмене защищаемой информацией. В таких криптосистемах нет необходимости и в арбитрах. Суть разработанного подхода заключается в том, что в обмене защищаемыми документами каждый абонент использует пару взаимосвязанных ключей - открытый и секретный. Отправитель подписываемого документа передает получателю открытый ключ. Он может это сделать любым несекретным способом или поместить ключ в общедоступный справочник. При помощи открытого ключа получатель проверяет подлинность получаемой информации. Секретный ключ, при помощи которого подписывалась информация, хранится в тайне от всех.
Можно заметить, что в данной схеме абоненты используют различные ключи, что не позволяет мошенничать ни одной из сторон. Подробный анализ цифровой подписи на основе криптосистем с открытыми ключами показывает, что она полностью удовлетворяет требованиям, предъявляемым к ней и указанным в начале статьи. В настоящий момент широкого известны цифровые подписи, построенные по алгоритмам RSA, Эль-Гамаля, Шнорра, Рабина и математического аппарата эллиптических кривых.
Подпись документов при помощи симметричных криптосистем
Первые варианты цифровой подписи были реализованы при помощи симметричных криптосистем, в которой абоненты, участвующие в обмене сообщениями, используют один и тоже секретный ключ для простановки и проверки подписи под документом. В качестве алгоритма криптографического преобразования может использоваться любая из симметричных криптосистем, обладающая специальными режимами функционирования (например, DES, ГОСТ 28147-89 и т.п.).
Процедура подписи документов при помощи симметричной криптосистемы может выглядеть следующим образом:
1. Алекс и Юстас обладают одинаковым секретным ключом K.
2. Алекс зашифровывает цифровое сообщение, используя ключ K, и посылает зашифрованное сообщение Юстасу. При этом, как уже отмечалось, используется криптосистема, обладающая специальными механизмами функционирования, например ГОСТ 28147-89 в режиме выработки имитовставки.
3. Юстас расшифровывает сообщение при помощи ключа K.
Так как только Алекс и Юстас обладают секретным ключом, то тем самым обеспечивается гарантия, что сообщение подписано именно Алексом, а не стариком Мюллером. Однако, данная схема применима только в тех сетях, в которых можно дать стопроцентную гарантирую надежности каждого из абонентов, т.к. в обратном случае существует потенциальная возможность мошенничества со стороны одного из абонентов, владеющих секретным ключом.
Для устранения указанного недостатка была предложена схема с доверенным арбитром. В данной схеме помимо Алекса и Юстаса существует арбитр - радистка Кэт. Она может обмениваться сообщениями и с Алексом, и с Юстасом, и владеет секретными ключами обоих - KА и KЮ. Процедура подписания документов в данной схеме выглядит следующим образом:
1. Алекс зашифровывает сообщение, используя ключ KА, и посылает его Кэт.
2. Кэт расшифровывает сообщение, также используя ключ KА.
3. Расшифрованное сообщение Кэт зашифровывает на ключе Юстаса KЮ.
4. Данное сообщение Кэт посылает Юстасу.
5. Юстас расшифровывает сообщение, полученное от Кэт, используя ключ KЮ.
Насколько эффективна данная схема? Рассмотрим ее с учетом вышеуказанных требований, предъявляемых к цифровой подписи.
Во-первых, Кэт и Юстас знают, что сообщение пришло именно от Алекса. Уверенность Кэт основана на том, что секретный ключ KА имеют только Алекс и Кэт. Подтверждение Кэт служит доказательством Юстасу. Во-вторых, только Алекс знает ключ KА (и Кэт, как доверенный арбитр). Кэт может получить зашифрованное сообщение на ключе KА только от Алекса. Если Мюллер пытается послать сообщение от имени Алекса, то Кэт сразу обнаружит это на 2-м шаге. В-третьих, если Юстас пытается использовать цифровую подпись, полученную от Кэт, и присоединить ее к другому сообщению, выдавая его за сообщение от Алекса, это выявляется. Арбитр может потребовать от Юстаса данное сообщение и затем сравнивает его с сообщением, зашифрованном на ключе KА. Сразу выявляется факт несоответствия между двумя сообщениями. Если бы Юстас попытался модифицировать присланное сообщение, то Кэт аналогичным способом выявила бы подделку. В-четвертых, даже если Алекс отрицает факт посылки подписанного сообщения, подтверждение от Кэт говорит об обратном.
В случае возникновения спорных ситуаций, например, связанных с отказом отправителя от факта подписания документа, используются услуги третьей, независимой стороны, так называемого арбитра, который расследует каждую такую ситуацию и принимает решение в пользу одной из сторон, участвующих в обмене данными.
Можно заметить, что самым критичным звеном этой схемы является именно арбитр. Во-первых, он должен быть действительно независимой ни от кого стороной. А во-вторых, арбитр должен быть абсолютно безошибочным. Ошибка в рассмотрении даже одной из нескольких тысяч спорных ситуаций подорвет доверие не только к арбитру, но и ко всем предыдущим подписанным документам, достоверность которых удостоверялась арбитром.
Именно поэтому, несмотря на теоретическую возможность применения симметричных криптосистем, на практике для выработки подписи они не используются, поскольку требуют дорогостоящих и громоздких мероприятий по поддержанию достаточного уровня достоверности передаваемых данных.
Подводные камни безопасности в криптографии.
Перевод –
Журнальные статьи любят описывать криптографические продукты в терминах алгоритмов и длины ключей. Алгоритмы благозвучны: их описание может быть немногословным и их легко сравнивать друг с другом. "128-битные ключи означают высокую степень защиты". "Тройной DES означает высокую степень защиты". "40-битные ключи означают низкий уровень защиты". "2048-битный RSA лучше 1024-битного RSA".
Но в действительности всё не так просто. Более длинные ключи не всегда означают лучшую защиту. Сравним криптографический алгоритм с замком на Вашей входной двери. Большинство дверных замков имеют четыре металлических штифта, каждый из которых может находиться в одном из десяти положений. Ключ устанавливает штифты в особой комбинации. Если ключ установит их все правильно, замок откроется. Таким образом, может быть только 10000 различных ключей и взломщик, готовый испробовать все 10000, обязательно попадёт к Вам в дом. Но улучшенный замок с десятью штифтами, дающий 10 миллиардов возможных ключей, возможно, не сделает Ваше жилище безопаснее. Взломщики не испытывают каждый возможный ключ (атака "в лоб"); большинство даже не настолько хитры, чтобы взломать замок (криптографическая атака на алгоритм). Они разбивают окна, выбивают двери, переодеваются полицейскими или отнимают ключи под дулом пистолета. Одна шайка похитителей предметов искусства обходила домашние системы безопасности, пропиливая стены дома цепной пилой. Лучшие замки не спасут от таких атак.
Сильная криптография значит очень много, когда всё сделано верно, но панацеей она не является. Сосредоточение на криптографических алгоритмах, сопряжённое с игнорированием остальных аспектов безопасности похоже на защиту дома не постройкой забора вокруг него, а установкой огромного столба в надежде, что противник налетит прямо на него. Сообразительный нападающий просто обойдёт алгоритмы.
Counterpane (имеется ввиду Counterpane Internet Security, Inc.) потратила много лет на разработку, анализ и взлом криптографических систем. Пока мы занимаемся исследованием опубликованных алгоритмов и протоколов, большая часть нашей работы состоит в проверке реальных продуктов. Мы разрабатывали и анализировали системы, которые защищают секреты, обеспечивают конфиденциальность и правомочность, способствуют коммерции. Мы работали с программным обеспечением, автономным аппаратным обеспечением и всем, что стоит между ними. Мы взламывали некоторые алгоритмы, но почти всегда находились способы атаки, позволяющие полностью обойти сами алгоритмы. Мы не пытаемся пробовать каждый возможный ключ или даже искать недостатки в алгоритмах. Мы используем ошибки в проектировании, реализации и установке. Иногда мы изобретаем новый способ взлома системы, но, по большей части, мы используем те же старые ошибки, которые разработчики повторяют снова и снова.
Построение надёжных криптографических систем.
Разработчики систем безопасности занимают то, что прусский генерал Карл фон Клаушвиц (Carl von Clausewitz) назвал "позицией в осаде". Хорошая система безопасности должна защищать от любых возможных атак, пусть даже неизвестных на данный момент. Злоумышленники, с другой стороны, должны найти лишь одну ошибку для того, чтобы система была взломана. И они могут мошенничать, сговариваться, дожидаться, пока развитие технологии предоставит им новые инструменты. Они могут атаковать систему способом, о котором разработчик и не подозревал.
Построение надёжной криптографической системы - из разряда того, что сделать плохо легко, а хорошо – очень трудно. К сожалению, большинство людей не видят разницы. В других областях теории вычислительных систем функциональность служит для того, чтобы отличать хорошее от плохого: хороший алгоритм сжатия работает лучше плохого, плохой архиватор выглядит хуже при сравнительном анализе его возможностей. В криптографии – иначе. Только тот факт, что шифрующая программа работает, не означает, что она надёжна. Так случается с большинством продуктов: кто-то читает "Прикладную криптографию", выбирает алгоритм и протокол, удостоверяется в работоспособности и считает, что дело сделано. Но всё не так просто – функциональность не равноценна качеству и непродолжительное тестирование всегда выявляет дефекты системы безопасности. Слишком много продуктов идут на поводу у моды – они используют надёжную криптографию, сами надёжными не являясь.
Оригинал статьи (In English) .
Правовые аспекты
Данный вопрос достаточно сложен для того, чтобы подробно рассмотреть его со всех сторон. Постараюсь вкратце коснуться основных моментов. Одно из первых упоминаний о электронной цифровой подписи в отечественных законах приведено в Гражданском Кодексе (ст.160, п.2), согласно которому при совершении сделок допускается применение ЭЦП лишь в случаях и в порядке, предусмотренных законом, иными правовыми актами или соглашениями сторон.
В 1995 году был принят Федеральный Закон "Об информации, информатизации и защите информации". В пункте 3 статьи 5 говорится, что юридическая сила документа может подтверждаться электронной цифровой подписью. При этом "юридическая сила электронной цифровой подписи признается при наличии в автоматизированной информационной системе программно-технических средств, обеспечивающих идентификацию подписи установленного режима их использования". Однако "право удостоверять идентичность электронной цифровой подписи осуществляется на основании лицензии" (п.4).
Можно заметить, что и Гражданский Кодекс и Закон "Об информации, информатизации и защите информации" лишь подтверждают возможность применения ЭЦП, но никаким образом не регламентируют случаи и порядок ее использования. Эти задачи возлагаются на дополнительные правовые акты. Однако, никаких подзаконных актов, кроме наделавшего много шума Указа Президента № 334 от 3 апреля 1995 года, до сих пор не разработано. В Государственной Думе давно ждут рассмотрения Законы "Об электронном документе" и "Об электронной цифровой подписи". Но рассмотреть их планируется не ранее конца текущего года. А если учесть предстоящие выборы, то можно с уверенностью сказать, что о данных законопроектах заговорят не ранее 2000 года. Поэтому необходимо заметить, что для обеспечения юридической значимости цифровой подписи необходимо, чтобы в договоре об обмене электронными документами между сторонами была обязательно расписана процедура "порядка согласования разногласий". Без этой процедуры суд вправе не принимать в качестве доказательства документы, подписанные электронной цифровой подписью (Письмо Высшего Арбитражного Суда РФ от 19 августа 1994 г. № С1-7/ОП-587).
В Указе Президента от 3 апреля, в п.2 говорится о том, что использовать в информационно-телекоммуникационных системах средства ЭЦП, не имеющих сертификата Федерального агентства правительственной связи и информации (ФАПСИ), запрещено. Однако самое большое противоречие вызывает пункт 4, в котором запрещается деятельность нелицензированных ФАПСИ юридических и физических лиц, связанных с разработкой, реализацией, производством и эксплуатацией шифровальных средств (в т.ч. и систем цифровой подписи). Т.е. согласно данному пункту запрещено использовать системы цифровой подписи даже в домашних условиях. Однако статья 6 Закона "Об информации, информатизации и защите информации" говорит о том, что собственник информационного ресурса имеет право сам устанавливать правила защиты своей информации.
Известны и другие противоречия в законодательстве, связанном с цифровой подписью. Разрешить некоторые из них трудно без участия квалифицированных юристов. Хочется надеяться, что в ближайшие годы будут устранены имеющиеся правовые противоречия и разработаны новые законодательные акты, в полной мере удовлетворяющие требованиям пользователей и веяниям современных информационных технологий.
Хочется отметить работы, ведущиеся в этой области в Ассоциации Документальной Электросвязи. Во-первых, в Комитете по защите информации ведутся работы по реализации защищенной электронной почты X.400, невозможной без ЭЦП. Работы в области правового обеспечения ЭЦП ведутся также в Комитетах по электронному ведению бизнеса и Комитете по стандартизации.
Предупреждение атак или обнаружение атак.
Большинство криптографических систем зависят от предупреждения как от единственного способа защиты: криптография спасает людей от мошенничества, лжи, злоупотреблений и т.д. Защита никогда не должна быть ограниченной. Сильная система также пытается обнаруживать факты злоупотреблений и ограничивать эффект любых атак. Один из наших фундаментальных принципов проектирования состоит в предположении, что рано или поздно любая система будет успешно атакована, возможно, совершенно неожиданным способом и с совершенно неожиданными результатами. Важно иметь возможность обнаружить такую атаку и затем ограничить её, чтобы быть уверенным, что нанесённый ущерб будет минимальным.
Важнее то, что после обнаружения атаки, система нуждается в восстановлении: генерации новой пары ключей, обновлении протокола с запретом использования старого, удаления из системы дискредитированного узла и т.д. К сожалению, многие системы не собирают достаточно данных для предоставления контрольного следа, или не в состоянии защитить эти данные от изменения. Counterpane провела значительную работу по защите журналов контрольной проверки в системах электронной коммерции, по большей части, в ответ на проекты систем, которые могут быть полностью разрушены в результате успешной атаки. Такие системы должны не только обнаруживать атаки, но и давать убедительные улики для суда и присяжных.
Распределение ключей
Очень важный вопрос при выборе системы электронной цифровой подписи - это распределение ключей между абонентами, участвующими в обмене защищаемыми документами. Такое распределение может осуществляться двумя способами:
Путем создания центра генерации и распределения ключей. Недостаток такого подхода очевиден. Центр обладает полной информацией о том, кто и какой ключ использует. Компрометация центра распределения приводит к компрометации всей передаваемой между абонентами этого центра информации. Кроме того, знание секретных ключей абонентов позволяет нечистым на руку сотрудникам центра фальсифицировать определенные документы, передаваемые в системе обмена информацией. Путем прямого обмена ключами между абонентами, которые хотят обмениваться подписанными сообщениями. В этом случае основная задача - подтверждение подлинности каждого абонента из участвующих в обмене.
Подтверждение подлинности абонентов в последнем случае может осуществляться следующим образом:
Непосредственно между абонентами. Данный метод применяется в том случае, если абонентов всего двое. Для обмена ключами в данном случае может быть использован алгоритм распределения ключей, например, разработанный в 1976 году криптографами Диффи и Хеллманом. Существуют и другие варианты обмена ключами. Например, при помощи симметричных криптосистем или фельдъегерской службы. Однако, в распределенных сетях, насчитывающих не один десяток абонентов, такие варианты не применимы из-за возникающих сложностей. С использованием посредника (арбитра). Данный метод может применяться в корпоративных сетях, в которых существует так называемый центр верификации или сертификации ключей. Данный центр удостоверяет ключи, используемые для проверки подписи. Подтверждение подлинности ключей может реализовываться или путем формирования справочника открытых ключей, или путем выдачи сертификатов, которые передаются вместе с сообщением, требующим проверки. Данный сертификат представляют собой ключ для проверки подписи и некоторую аутентифицирующую информацию, скрепленные подписью Центра сертификации. В данном случае достаточно проверить подпись Центра в сертификате, чтобы удостовериться в подлинности ключа абонента. С использованием двух и более посредников. Этот метод, являющийся комбинацией двух предыдущих, может применяться в том случае, когда необходимо обеспечить обмен подписанными сообщениями между несколькими корпоративными сетями, в каждой из которых существует свой центр сертификации.
Распространение ключей
Ясно, что в обоих криптосистемах нужно решать проблему распространения ключей.
В симметричных методологиях эта проблема стоит более остро, и поэтому в них ясно определяется, как передавать ключи между участниками взаимодействия до начала взаимодействия. Конкретный способ выполнения этого зависит от требуемого уровня безопасности. Если не требуется высокий уровень безопасности, то ключи можно рассылать с помощью некоторого механизма доставки (например, с помощью простой почты или курьерской службы). Банки, например, используют почту для рассылки PIN-кодов. Для обеспечения более высокого уровня безопасности более уместна ручная доставка ключей ответственными за это людьми, возможно по частям несколькими людьми.
Асимметричные методологии пытаются обойти эту проблему с помощью шифрования симметричного ключа и присоединения его в таком виде к зашифрованным данным. А для распространения открытых асимметричных ключей, используемых для шифрования симметричного ключа, в них используются центры сертификации ключей. CA, в свою очередь, подписывают эти открытые ключи с помощью секретного асимметричного ключа CA. Пользователи такой системы должны иметь копию открытого ключа CA. Теоретически это означает, что участникам взаимодействия не нужно знать ключей друг друга до организации безопасного взаимодействия.
Сторонники асимметричных систем считают, что такого механизма достаточно для обеспечения аутентичности абонентов взаимодействия.
Но проблема все равно остается. Пара асимметричных ключей должна создаваться совместно. Оба ключа, независимо от того, доступны они всем или нет, должны быть безопасно посланы владельцу ключа, а также центру сертификации ключей. Единственный способ сделать это - использовать какой-либо способ доставки при невысоких требованиях к уровню безопасности, и доставлять их вручную - при высоких требованиях к безопасности.
Проблема с распространением ключей в асимметричных системах состоит в следующем:
X.509 подразумевает, что ключи безопасно раздаются, и не описывает способ решения этой проблемы - а только указывает на существование этой проблемы. Не существует стандартов для решения этого. Для безопасности ключи должны доставляться вручную (независимо от того, симметричные они или асимметричные). Нет надежного способа проверить, между какими компьютерами осуществляется взаимодействие. Есть вид атаки, при котором атакующий маскируется под CA и получает данные, передаваемые в ходе взаимодействия. Для этого атакующему достаточно перехватить запрос к центру сертификации ключей и подменить его ключи своими. Эта атака может успешно продолжаться в течение длительного времени. Электронная подпись ключей центром сертификации ключей не всегда гарантирует их аутентичность, так как ключ самого CA может оказаться скомпрометированным. X.509 описывает способ электронной подписи ключей CA центрами сертификации ключей более высокого уровня и называет его "путь сертификации". X.509 рассматривает проблемы, связанные с проверкой корректности открытого ключа, предполагая, что эта проблема может быть решена только при отсутствии разрыва в цепочке доверенных мест в распределенном справочнике открытых ключей пользователей. Нет способа обойти это. X.509 предполагает, что пользователь уже имеет доступ к открытому ключу CA. Как это осуществляется, в нем не определяется. Компрометация центра сертификации ключей весьма реальная угроза. Компрометация CA означает. Что все пользователи этой системы будут скомпрометированы. И никто не будет знать об этом. X.509 предполагает, что все ключи, включая ключи самого CA, хранятся в безопасном месте. Внедрение системы справочников X.509 (где хранятся ключи) довольно сложно, и уязвимо к ошибкам в конфигурации. В настоящее время слишком мало людей обладают техническими знаниями, необходимыми для правильного администрирования таких систем. Более того, понятно, что на людей, занимающих такие важные должности, может быть оказано давление. CA могут оказаться узким местом. Для обеспечения устойчивости к сбоям X.509 предлагает, чтобы база данных CA была реплицирована с помощью стандартных средств X.500; это значительно увеличит стоимость криптосистемы. А при маскараде под CA будет трудно определить, какая система была атакована. Более того, все данные из базы данных CA должны посылаться по каналам связи каким-то образом. Система справочников X.500 сложна в установке, конфигурировании и администрировании. Доступ к этому справочнику должен предоставляться либо с помощью дополнительной службы подписки, либо организации придется самой ее организовывать. Сертификат X.509 предполагает, что каждый человек имеет уникальное имя. Выделение имен людям - задача еще одной доверенной службы - службы именования. Сеансовые ключи, несмотря на то, что шифруются, все-таки передаются по незащищенным каналам связи.
Несмотря на все эти серьезные недостатки пользователь должен неявно доверять асимметричной криптосистеме.
Управлением ключами называется их распределение, аутентификация и регламентация порядка использования. Независимо от вида используемой криптосистемы ключами надо управлять. Безопасные методы управления ключами очень важны, так как многие атаки на криптосистемы имеют объектом атаки процедуры управления ключами.
| Процедура | Комментарии |
| Физическая раздача ключей | Курьеры и ручная выдача - вот два распространенных примера этой процедуры. Конечно, из них двоих лучше ручная выдача. Серьезные организации имеют инструкции, описывающие порядок выдачи ключей. Раздача ключей может аудироваться и протоколироваться, но это все-таки не защитит ее до конца от компрометации отдельными людьми. Используется как симметричными, так и асимметричными криптосистемами. Несмотря на заявления о том, что в асимметричных криптосистемах не возникает проблем, связанных с физической доставкой ключей, на самом деле они есть. X.509 предполагает, что создатель ключей будет передавать асимметричный секретный ключ пользователю (и/или асимметричный открытый ключ CA) физически безопасным способом, и что предприняты соответствующие меры физической безопасности, чтобы защитить создателя и проводимые им операции с данными от атак. |
| Выдача общего ключа участникам взаимодействия центром выдачи ключей | Может использоваться как симметричными, так и асимметричными криптосистемами. Так как при данном способе каждый пользователь должен каким-то образом безопасно взаимодействовать с центром выдачи ключей в самом начале работы, то это просто еще один случай, когда начальный обмен ключами является проблемой. Если центр скомпрометирован, то обеспечение безопасности последующих запросов на выдачу ключей проблематично, а безопасность ранее выданных ключей зависит от криптосистемы. |
| Предоставление центром сертификации ключей доступа к открытым ключам пользователей и выдача секретных ключей пользователям | Используется асимметричными криптосистемами. Пользователи должны доверять всей этой системе. Всего лишь одна успешная атака компрометирует всю систему. Иерархическая система аттестации ключей приводит к появлению большего числа потенциальных уязвимых мест - CA должен публиковать свой асимметричный открытый ключ и предоставлять его сертификат, выданный CA более высокого уровня. Асимметричные секретные ключи CA должны храниться в безопасном месте, так как их компрометация может привести к успешным атакам, которые нельзя будет обнаружить. |
| Сеть доверия | Используется в асимметричных криптосистемах. Пользователи сами распространяют свои ключи и следят за ключами других пользователей; доверие заключатся в неформальном способе обмена ключами. |
| Метод Диффи-Хеллмана | Обмен секретным ключом по незащищенным каналам связи между двумя пользователями, которые до этого не имели общего секретного ключа. Не может использоваться для шифрования или расшифровки сообщений. Основывается на сложности взятия логарифма в конечных полях. При правильном выборе достаточно больших элементов полей решить проблему расчета дискретного логарифма невозможно. Уязвим к атаке "активное вмешательство в соединение". Запатентован PKP (Public Key Partners) |
Реализации
Описание Fortezza является интересным само по себе, однако как пользователей,так и исследователей этой технологии не могут не заинтересовать прикладныеаспекты конкретных разработок. В таблице 2 содержатся основные параметры3-х известных автору реализаций технологии Fortezza на основе информации,полученной по сети Internet.
| Название, характеристики |
Windows 3.1
Windows 95
Windows NT
SCO ODT
Windows 3.1
Windows 95
Windows NT
Apple Macintosh
SCO ODT
UNIX-HP/UX
IBM AIX
SUN OS и Solaris
Windows 3.1
Windows 95*
Windows NT*
Apple Macintosh7.x*
OSF*
UNIX*
IBM AIX*
HPBLS*
шифрование
цифровая подпись
верификация подписи
хэширование
> 1.4 Мбайт/с
23 мс
39 мс
н/д
> 1.1 Мбайт/с
67 мс
н/д
н/д
2 Мбайт/с
<50 мс
<100 мс
2 Мбайт/с
напряжение
мощность
+5В
н/д
+5В 605 мВт
(62.5 мВт**)
+5В
< 1Вт
Таблица 2. Характеристики производимых криптокарт Fortezza
Примечания: * - в будущем, ** - в режиме standby, н/д - нет данных.
 |
 |
 |
Рекомендации и выбор вида шифра для применения в сети доступа
,
Вісник українського будинку економічних та науково-технічних знань. #3, 2005
Основное требование, предъявляемое к выбору алгоритмов криптографической защиты информации при канальном шифровании заключается в возможности закрытия нефиксированных объемов передаваемой информации с минимальными временными задержками.
Так как для передачи данных и речевых сообщений могут используются каналы недостаточно высокого качества, то любая криптографическая система, увеличивающая и без того нередкие ошибки, неприменима - неразмножение криптографическим алгоритмом ошибок, вносимых каналом связи.
При использовании сквозного шифрования требования к неразмножению криптоалгоритмом ошибок, вносимых каналом связи не столь важно. При сквозном шифровании на нижестоящих уровнях выполняется помехоустойчивое кодирование. Но криптоалгоритмы сквозного шифрования должны кроме закрытия передаваемой информации давать возможность надежной аутентификации.
Требования, предъявляемые к выбору алгоритмов криптографической защиты информации при сквозном шифровании:
Интерактивные данные закрывать с минимальной временной задержкой.
К закрытию неинтерактивных данных особых требований не предъявляется.
При комбинированном шифровании работа с ключами ведется так: КСЗИ и АК АТС отвечают за ключи, используемые при канальном шифровании, а о ключах, применяемых при сквозном шифровании, заботятся сами пользователи. Применяются потоковые (можно потоковый (наложение гаммы) режим работы блочного шифра), сверточные шифры
Основным недостатком потоковых шифров является необходимость передачи информации для начальной инициализации (синхропосылка) перед заголовком сообщения, которая должна быть принята до расшифровывания любого сообщения. Это связано с тем, что синхропосылка может также являться и секретным ключом (частью секретного ключа). Передача синхропосыки в виде, в котором она будет применяться в алгоритме шифрования по каналу передачи данных может создать угрозу криптографической стойкости системы, и поэтому всегда необходимо применять дополнительный ключ, с помощью которого сихропосылка будет закрываться, либо использовать в алгоритме шифрования ключезависимую модификацию синхропосылки, как это реализовано в ГОСТ 28147-89.
В ГОСТ 28147-89 синхропосылка (начальное заполнение) передается в открытом виде, но в алгоритме шифрования используется результат преобразования начального заполнения по циклу 32-З: Ω0 = Ц32-3(S), где Ω0 - вектор начального заполнения рекуррентного генератора последовательности чисел (РГПЧ), Ц32-3 - базовый цикл зашифрования, S - синхропосылка.
На основании приведенных рассуждений получим следующие результаты:
Канальное шифрование - потоковые шифры (потоковый режим работы блочного шифра может не подойти).
Сквозное шифрование:
Для закрытия итерактивных данных могут подойти сверточные шифры, либо блочные шифры в режиме гаммирования.
Для закрытия неитерактивных данных могут подойти как сверточные шифры (для упрощения конструкции КСЗИ) так и блочные шифры.
Криптосистемы с открытым ключом могут использоваться для механизмов аутентификации КСЗИ и ключевого обмена между КСЗИ.
Security Pitfalls in Cryptography
by Bruce Schneier
Cryptography Consultant
e-mail:
Copyright Counterpane Internet Security, Inc., 2001
Сертификаты
Как следует из сказанного выше, в технологии Fortezza должен существоватьпротокол, регламентирующий выдачу и распространение открытых ключей пользователей.Открытые ключи ассоциируются с их владельцами с помощью так называемых"сертификатов". Сертификат представляет собой структуру данных,связывающую идентификатор пользователя, открытые ключи, предназначенныедля алгоритмов KEA и DSA, а также информацию о лице, выдавшем сертификат.С целю защиты от подделки сертификат защищается цифровой подписью выдавшегосертификат лица. Сертификаты и пары секретных/открытых ключей образуютоснову системы управления ключами технологии Fortezza.
В качестве основы системы аутентификации Fortezza использует схему аутентификациисертификатов X.509 и соглашения о наименовании объектов X.500. ТехнологияFortezza различает две структуры сертификатов. Под "сертификатом Fortezza"понимается внутренняя структура данных технологии Fortezza, под "сертификатомX.509" - блок данных стандарта X.509, содержащийся в сертификате Fortezza(см. Рис.5.).
2820 байт
| метка | флажки | размер | DSA | KEA | DSA | DSA | DSA | DSA | DSA | KEA | KEA | KEA | KEA | KEA | сертификат | |||||||||||||
| данных | Private (X) | Private (X) | размер PG | размер Q | P | Q | G | размер PG | размер Q | P | Q | G | X.509 | |||||||||||||||
| 32 | 16 | 4 | 48 | 48 | 4 | 4 | 128 | 48 | 128 | 4 | 4 | 128 | 48 | 128 | 2048 байт |
Рис. 5.
Каждый сертификат Fortezza состоит из двух пар открытых/секретных ключей(одна из них предназначена для использования в KEA, другая - в DSA) и соответствующихим значений параметров P, Q и G. Сертификат X.509 содержит открытые составляющиеэтих ключей. Открытые ключи всегда доступны пользователю карты. Ключи хранятсяв закодированном виде: секретные - с помощью локальных ключей пользователяKs (ключ Ks имеет размер 80 бит, находится в специальном регистре криптокартыи становится доступным после успешного ввода PIN пользователя), открытые- с помощью ASN.1. Поле данных размером 2048 байт, зарезервированное длясертификата X.509, может использоваться для хранения любой информации (биометрическихданных, фотоизображений), если только такие "сертификаты" неиспользуются в криптографических функциях. Приложения могут загружать этиданные в энергонезависимую память карты и сохранять их там продолжительноевремя.
Сертификаты X.509 могут быть размещены в базу данных специализированного"сертификационного сервера" (нескольких серверов) или распределеныпо сети и сохранены локально в картах всех участников информационного обмена.Единственным условием является доступность сертификата для криптографическихфункций приложений Fortezza. Некоторые приложения позволяют включать сертификатотправителя в заголовок сообщения, предоставляя получателю возможностьдинамически создавать локальную базу сертификатов абонентов. Такая локальнаябаза может служить своего рода "кэшем" сертификатов, что делаетвозможным посылку сообщений без обращения к серверу сертификатов. Однако,долгое использование локальной базы может привести к устареванию содержащихсяв ней сертификатов.
Таблица 1 содержит описание всех криптографических функций.
Криптографическая функция
Таблица 1. Криптографические функции Fortezza.
Симметричные алгоритмы
Для шифрования и расшифровки используются одни и те же алгоритмы. Один и тот же секретный ключ используется для шифрования и расшифровки. Этот тип алгоритмов используется как симметричными, так и асимметричными криптосистемами.
| Тип | Описание | |
| DES (Data Encryption Standard) | Популярный алгоритм шифрования, используемый как стандарт шифрования данных правительством США.
Шифруется блок из 64 бит, используется 64-битовый ключ (требуется только 56 бит), 16 проходов Может работать в 4 режимах: Электронная кодовая книга (ECB-Electronic Code Book ) - обычный DES, использует два различных алгоритма. Цепочечный режим (CBC-Cipher Block Chaining), в котором шифрование шифрование блока данных зависит от результатов шифрования предыдущих блоков данных. Обратная связь по выходу (OFB-Output Feedback), используется как генератор случайных чисел. Обратная связь по шифратору (CFB-Cipher Feedback), используется для получения кодов аутентификации сообщений. | |
| 3-DES или тройной DES | 64-битный блочный шифратор, использует DES 3 раза с тремя различными 56-битными ключами.
Достаточно стоек ко всем атакам | |
| Каскадный 3-DES | Стандартный тройной DES, к которому добавлен механизм обратной связи, такой как CBC, OFB или CFB
Очень стоек ко всем атакам. | |
| FEAL (быстрый алгоритм шифрования) | Блочный шифратор, используемый как альтернатива DES
Вскрыт, хотя после этого были предложены новые версии. | |
| IDEA (международный алгоритм шифрования) | 64-битный блочный шифратор, 128-битовый ключ, 8 проходов
Предложен недавно; хотя до сих пор не прошел полной проверки, чтобы считаться надежным, считается более лучшим, чем DES | |
| Skipjack | Разработано АНБ в ходе проектов правительства США "Clipper" и "Capstone".
До недавнего времени был секретным, но его стойкость не зависела только от того, что он был секретным. 64-битный блочный шифратор, 80-битовые ключи используются в режимах ECB, CFB, OFB или CBC, 32 прохода | |
| RC2 | 64-битный блочный шифратор, ключ переменного размера
Приблизительно в 2 раза быстрее, чем DES Может использоваться в тех же режимах, что и DES, включая тройное шифрование. Конфиденциальный алгоритм, владельцем которого является RSA Data Security | |
| RC4 | Потоковый шифр, байт-ориентированный, с ключом переменного размера.
Приблизительно в 10 раз быстрее DES. Конфиденциальный алгоритм, которым владеет RSA Data Security | |
| RC5 | Имеет размер блока 32, 64 или 128 бит, ключ с длиной от 0 до 2048 бит, от 0 до 255 проходов
Быстрый блочный шифр Алгоритм, которым владеет RSA Data Security | |
| CAST | 64-битный блочный шифратор, ключи длиной от 40 до 64 бит, 8 проходов
Неизвестно способов вскрыть его иначе как путем прямого перебора. | |
| Blowfish. | 64-битный блочный шифратор, ключ переменного размера до 448 бит, 16 проходов, на каждом проходе выполняются перестановки, зависящие от ключа, и подстановки, зависящие от ключа и данных.
Быстрее, чем DES Разработан для 32-битных машин | |
| Устройство с одноразовыми ключами | Шифратор, который нельзя вскрыть.
Ключом (который имеет ту же длину, что и шифруемые данные) являются следующие 'n' бит из массива случайно созданных бит, хранящихся в этом устройстве. У отправителя и получателя имеются одинаковые устройства. После использования биты разрушаются, и в следующий раз используются другие биты. | |
| Поточные шифры | Быстрые алгоритмы симметричного шифрования, обычно оперирующие битами (а не блоками бит).
Разработаны как аналог устройства с одноразовыми ключами, и хотя не являются такими же безопасными, как оно, по крайней мере практичны. |
Список литературы
1. Bruce Schneier. Applied Cryptography, Second edition. John Wiley & Sons, 1996
2. Брюс Шнайер. Слабые места криптографических систем. "Открытые системы", №1, 1999.
3. Ю. Мельников. Электронная цифровая подпись: всегда ли она подлинная? Банковские технологии, №5, 1995.
Стандарты
В России в 1994 году были приняты стандарты ГОСТ Р 34.10-94 "Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма" и ГОСТ Р 34.11-94 " Криптографическая защита информации. Функция хэширования". Чем могут помочь пользователю данные стандарты? Во-первых, они должны гарантировать криптостойкость, т.е. надежность реализованных по ним алгоритмов. Во-вторых, применение стандартов должно обеспечить совместимость продуктов различных производителей. Однако есть и проблемы при использовании принятых стандартов.
Стандарты ГОСТ Р 34.10-94 и ГОСТ Р 34.11-94 описывают лишь процедуры выработки и проверки ЭЦП и хэш-функции. За пределами их рассмотрения остается такой важный вопрос, как распространение и генерация ключей, защита от несанкционированного доступа к ключевой информации и т.д. Поэтому зачастую продукты, реализующие один и тот же стандарт, несовместимы между собой. На российском рынке средств защиты информации существует несколько известных систем, в которых реализованы указанные стандарты (Верба-О, Криптон и т.д.), но между собой эти системы не совместимы.
Как уже отмечалось, использование стандарта должно гарантировать, что документы, подписанные при помощи ГОСТ Р 34.10-94, теоретически не могут быть подделаны за приемлемое для злоумышленника время. Однако на практике дело не всегда обстоит таким образом. Связано это с тем, что стандарт описывает алгоритм математическим языком, в то время как пользователи сталкиваются уже с его реализацией. А при реализации могут быть допущены различные ошибки, которые сводят на нет все достоинства алгоритма. Кроме того, эффективное применение систем ЭЦП зависит от их правильной эксплуатации. Например, хранение секретных ключей для генерации цифровой подписи на доступном всем жестком диске позволяет злоумышленнику получить к ним доступ и в дальнейшем подделывать документы, подписанные на этих ключах.
Поэтому далеко не всегда указанные системы обеспечивают необходимый уровень защищенности.
Требования пользователей
Если обратиться к документации на различные системы, реализующие ЭЦП, то можно заметить, что производители, особенно в России, уделяют максимум внимания математическим аспектам реализованных алгоритмов. Десятки страниц посвящены тому, какова криптостойкость алгоритма и сколько лет потребуется злоумышленнику на подделку подписанного документа. Но как ни парадоксально это прозвучит, на практике пользователей очень мало волнуют эти вопросы. Если система реализует некоторый стандарт, то для конечного пользователя этого факта достаточно. Тем более что проверить правильность приводимых в документации выкладок сможет только квалифицированный математик-криптограф, которых в России очень мало. В первую очередь пользователи интересуются потребительскими свойствами предлагаемых систем, возможностям их встраивания в уже существующую технологию обработки информации и т.п. Рассмотрим более подробно эти и другие вопросы, задаваемые пользователями при приобретении систем, реализующих электронную цифровую подпись.
Скорость - это один из основных параметров, на которые следует обращать внимание при выборе системы цифровой подписи. Особенно в системах связи, в которых осуществляется очень интенсивный обмен данными и передаваемая информация должна защищаться от подделки. Данный параметр слагается из двух составляющих: скорости генерации подписи и скорости ее проверки, и существенно зависит от скорости выработки хэш-функции, а также типа ЭВМ, на которой осуществляется генерация или проверка ЭЦП.
Немаловажным параметром является длина подписи. Например, в системах диспетчерского управления, в которых постоянно передается большое число переменных малой длины, использование российского стандарта для подписи всех данных неэффективно.
Поскольку при приобретении системы цифровой подписи, как правило, у заказчика уже сложилась информационная инфраструктура, то очень часто на первое место выходит вопрос об интеграции приобретаемой системы в принятую технологию обработки информации. Например, если в качестве средства отправки электронной почты используется Microsoft Outlook, то необходимо, чтобы система ЭЦП могла быть встроена в эту почтовую программу. Такую возможность предлагают многие зарубежные и некоторые российские системы ЭЦП, например, PGP (Pretty Good Privacy), которая также может быть встроена в почтовую программу Eudora, наравне с Microsoft Outlook, широко распространенную в России. Если система ЭЦП не поддерживает используемое у заказчика программное обеспечение (например, потому что оно разработано самим заказчиком), то поставщик должен поставлять интерфейс (API) для встраивания возможностей работы с цифровой подписью в систему заказчика. Такую возможность предлагают многие российские производители (например, МО ПНИЭИ, ЛАН КРИПТО, НИП "Информзащита"). Причем желательно, чтобы данный интерфейс существовал для различных операционных систем и платформ (Windows NT, Windows 9x, MS DOS, HP UX, AIX и т.д.).
Необходимо обратить внимание на предлагаемые механизмы или меры защиты от несанкционированного доступа к системе электронной цифровой подписи. Должны быть предусмотрены действия, выполняемые в случае компрометации ключей одного из пользователей (например, занесение их в "черные списки" и рассылка всем пользователям системы). Кроме того, должна контролироваться целостность как системы ЭЦП в целом, так и ее компонентов (например, журналов регистрации действий). В документации на некоторые российские системы ЭЦП есть рекомендации по применению систем защиты информации от несанкционированного доступа. Данные системы, в частности, позволяют ограничить круг лиц, имеющих право запуска системы цифровой подписи. Одной из таких систем является сертифицированная в Гостехкомиссии России система Secret Net, разработанная Научно-инженерным предприятием "Информзащита".
Немаловажным аспектом является юридическая поддержка предлагаемого решения. Если предложение системы ЭЦП исходит от компании-разработчика программного обеспечения, то она должна предоставить проект договора об обмене электронными документами с использованием ЭЦП. Если же компания предлагает обслуживание с применением систем ЭЦП, то следует внимательно ознакомиться с текстом заключаемого договора. В таком договоре или его проекте должно быть предусмотрено решение следующих вопросов:
Наличие процедуры урегулирования конфликтных ситуаций; Описание состава комиссии, расследующей возникающие конфликты; Ответственность сторон (в т.ч. и фирмы-разработчика).
Для реализации процедуры расследования конфликтных ситуаций система, в которой реализована цифровая подпись, должна поддерживать возможность хранения всех используемых ключей.
Окончательный выбор системы ЭЦП может быть определен наличием или отсутствием следующих дополнительных возможностей:
Постановка нескольких подписей под одним документом и их выборочная проверка; Хранение цифровой подписи не только в подписываемом документе, но и в отдельном файле; Использование командной строки для работы с системой ЭЦП; Подпись и проверка группы файлов; Постановка и проверка подписи под заданными фрагментами (полями) документа; Выработка и проверка групповой подписи; Совместное использование функций шифрования и цифровой подписи; Постановка подписи и ее проверка для участка оперативной памяти; Архивация использованных ключей; И т.д.
это одна из самых ценных
Информация - это одна из самых ценных вещей в современной жизни. Появление глобальных компьютерных сетей сделало простым получение доступа к информации как для отдельных людей, так и для больших организаций. Но легкость и скорость доступа к данным с помощью компьютерных сетей, таких как Интернет, также сделали значительными следующие угрозы безопасности данных при отсутствии мер их защиты:
Неавторизованный доступ к информации Неавторизованное изменение информации Неавторизованный доступ к сетям и другим сервисам Другие сетевые атаки, такие как повтор перехваченных ранее транзакций и атаки типа "отказ в обслуживании"
Выбор параметров криптографических алгоритмов и ключей
Потоковые шифры основываются на псевдослучайных (случайных) ключевых последовательностях - сгенерированных определенным образом последовательностях символов с заданными свойствами непредсказуемости (случайности) появления очередного символа. Генераторы ключевых последовательностей обычно базируются на комбинациях регистров сдвига и нелинейных булевых функциях.
Генераторы ключевых последовательностей характеризуются:
периодом повторения последовательности; статистическими свойствами порождаемых последовательностей; криптографической стойкостью генератора ключевой последовательности.
Если используется потоковое шифрование, тогда минимальный период должен удовлетворять условию: TΩ>>Tmax * V * n,(1)
где TΩ - минимальный период повторения последовательности,
Tmax - максимальное время непрерывной работы КСЗИ,
V - скорость передачи в канале связи,
t - разрядность последовательности на выходе генератора ключевой последовательности.
Безопасность любого алгоритма сосредоточена в ключе. Если используется криптографически слабый процесс для генерации ключей, то криптосистема в целом слаба. Злоумышленнику не нужно криптоанализировать алгоритм шифрования, он может криптоанализировать алгоритм генерации ключей.
Теоретически, любой шифровальный алгоритм с использованием ключа может быть вскрыт методом перебора всех значений ключа. Если ключ подбирается методом грубой силы (brute force), требуемая мощность компьютера растет экспоненциально с увеличением длины ключа. Ключ длиной в 32 бита требует 232 (около 109) шагов.
Тогда минимальную длину ключа в битах Nmin можно вычислить по формуле:
где T - время жизни передаваемых данных (определяется в соответствии с законодательством по степени секретности передаваемых данных). Хотя информация может устареть сразу после передачи ее по каналу связи. В этом случае время жизни передаваемых данных должно выбираться не менее 48 часов.
V - скорость подбора ключей, зависит от класса алгоритма шифрования и используемых злоумышленником ресурсов и может колебаться от 103 до 106 и выше, при использовании суперЭВМ либо распределенных вычислений.
Следует учесть, что некоторые алгоритмы могут иметь эквивалентные ключи (в иностранной литературе их называют ключи-дополнения) K* такие, что выполняется равенство:
f −1(C, K)=f −1(C, K*)=f*(C, K*)=P, (3)
где f* - функция, при использовании эквивалентного ключа K* , дающая такой же результат, как и функция расшифрования f −1 алгоритма.
При этом может оказаться, что злоумышленнику требуется перебрать только некоторую часть множества ключей.
Пример для режима наложения гаммы:
f(P, K)=P⊕Γ=C , тогда легальный пользователь вычислит f −1(C, K)=C⊕Γ=P .
Злоумышленник может найти такой ключ
В данном случае, эквивалентным ключом является инверсия основного ключа, а f* - инверсия функции сложения по модулю 2.
В итоге злоумышленнику необходимо вместо 2m операций перебора выполнить 2m-1 операций, где m - разрядность ключевой комбинации.
С учетом вышесказанного перепишем формулу (2) в виде:
Ψ - коэффициент, учитывающий наличие эквивалентных ключей. Для алгоритмов шифрования на основе гаммирования Ψ=2÷3 .
Для вычисления Ψ для других алгоритмов криптографической защиты информации необходимо проводить исследования для выявления эквивалентных ключей.
Следует учесть, что вычислительная мощь вычислительных средств удваивается каждые 18÷24 месяцев (Δt = 1,5÷2 года) - эмпирический закон Мура. Если необходимо, чтобы ключи были устойчивы к вскрытию грубой силой в течение 5 лет, то необходимо соответствующим образом планировать использование ключей.
С учетом вышесказанного перепишем формулу (4) в виде:
где [T']=[год]
Δt - срок, за который вычислительная мощь вычислительных средств удваивается (параметр удвоения), год.
Следует учесть, что параметр Δt нужно время от времени пересматривать, особенно в периоды смены поколений микросхем и внедрения новых достижений в технологии.
Пока обоснованным выглядит представление динамики роста вычислительной мощи со следующими значениями параметра удвоения: Δt = 2 года в период с 1971 г. по 1993 г., Δt = 4 года в период с 1993 г. по 1999 г. и Δt = 0.6 года от 1999 г.
Но эти числа дают только часть ответа. Дело в том, что машина заведомо раскрывающая ключ за год, имеет 8% шанс раскрыть ключ за месяц. Если при этом ключ меняют 1 раз в месяц, то есть 8% вероятность раскрыть ключ еще во время его использования.
Более того, пусть есть машина, отыскивающая ключ за месяц, а ключ меняется каждый час. Несмотря на то, что вероятность найти данный ключ за час всего 0,14%, вероятность найти правильный ключ до его смена за месяц использования такой схемы = 63%, причем эта цифра не зависит от частоты смена ключа.
Т.о. частая смена ключей позволяет разве что минимизировать последствия взлома системы, но во многих системах это все равно недопустимый риск.
Некоторые алгоритмы шифрования имеют криптографически слабые и полуслабые ключи - специфические ключи, менее безопасные чем другие ключи. Следует использовать специальные алгоритмы, которые используются для проверки при генерации ключей для устранения возможности выработки криптографически слабых (полуслабых) ключей.
в данной статье аспекты показывают,
Описанные в данной статье аспекты показывают, что выбор системы электронной цифровой подписи - непростая задача, решению которой необходимо уделить серьезное внимание. Не существует готовых рецептов. Правильный выбор - это не просто просмотр рекламных буклетов, полученных на выставке, или ознакомление с Web-сервером поставщика системы ЭЦП. Это кропотливый процесс, в котором должно учитываться множество факторов. Это и необходимость интеграции в принятую технологию обработки информации, и необходимость наличия сертификата ФАПСИ, и алгоритм распределения ключей, и т.д.
Сделайте правильный выбор - и Ваша информация будет надежно защищена от подделки.
Защита информации в сети доступа
,
Вісник українського будинку економічних та науково-технічних знань. #3, 2005
Среди всего многообразия способов несанкционированного перехвата информации особое место занимает анализ трафика в сети доступа, поскольку сеть доступа - самый первый и самый удобный источник связи между абонентами в реальном масштабе времени, и при этом самый незащищенный.
Сеть доступа имеет еще один недостаток с точки зрения безопасности - возможность перехвата речевой информации из помещений, по которым проходит телефонная линия, и где подключен телефонный аппарат (далее оконечное оборудование (ОО)), даже тогда, когда не ведутся телефонные переговоры. Для такого перехвата существует специальное оборудование, которое подключается к телефонной линии внутри контролируемого помещения или даже за его пределами. Требования к оборудованию противодействия данных угрозам описывают НД ТЗІ 2.3-002-2001, НД ТЗІ 2.3-003-2001, НД ТЗІ 4.7-001-2001 и некоторые другие нормативные документы.
В общем случае от ОО к АТС и обратно передаются:
сигналы управления и сигнализации стандартного оборудования (ТА, модем и т.д.);
сигналы передачи данных, речь;
сигналы сигнализации и управления нестандартного оборудования (охранная, пожарная сигнализация и др.).
Инсталляция центра сертификации
Для создания центра будем использовать адаптированный набор скриптов, написанных Ralf S. Engelschall.
Загрузите архив по ссылке http://slil.ru/25110674.
#tar -xjf CA_clean.tar.bz2 #cd CA_clean #export CAHOME=`pwd` #echo ${CAHOME}
Отредактируйте файл ca.conf под свои нужды:
[req] distinguished_name =req_distinguished_name x509_extensions = v3_ca prompt = no [req_distinguished_name] C= UA ST = UA L = Kiev O = GPAHARENKO-UA OU = ROOTCA CN = ca.gpaharenko.com.ua emailAddress = gpaharenko@gpaharenko.ua [v3_ca] basicConstraints = CA:true nsComment = "CA certificate of GPAHARENKO" nsCertType = sslCA, emailCA subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always
В скрипте createca.sh срок жизни сертификата равен 10 лет, вы можете изменить его в соответствии с вашей политикой. В этом же файле устанавливается длина ключа сертификата.
Генерируем корневой сертификат:
#./createca.sh Generating RSA private key, 4096 bit long modulus ...++ .................................................................................++ e is 65537 (0x10001) Enter pass phrase for ca.key: Verifying - Enter pass phrase for ca.key: Enter pass phrase for ca.key: #
Один и тот же пароль необходимо ввести 3 раза. Создаются файлы ca.key - закрытый ключ сертификата, ca.crt - корневой сертификат, ca.pfx - для некоторых приложений может понадобиться сертификат в таком формате.
#openssl x509 -text -in ca.crt |head -15 Certificate: Data: Version: 3 (0x2) Serial Number: b5:b5:a9:0e:3d:ed:fb:24 Signature Algorithm: sha1WithRSAEncryption Issuer: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Validity Not Before: Oct 31 13:57:31 2007 GMT Not After : Oct 28 13:57:31 2017 GMT Subject: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (4096 bit) Modulus (4096 bit):
#openssl rsa -text -in ca.key |head -5 Enter pass phrase for ca.key: writing RSA key Private-Key: (4096 bit) modulus: 00:c2:3c:f1:e6:56:b6:a6:87:4c:99:56:3f:03:df: 81:04:5b:b3:4a:40:3e:93:71:62:80:e9:3b:01:00: 21:33:91:3c:3f:6a:79:9e:81:97:8b:f4:3a:f0:b4:
#openssl x509 -text -in ca.pfx -inform der |head -15 Certificate: Data: Version: 3 (0x2) Serial Number: b5:b5:a9:0e:3d:ed:fb: 24 Signature Algorithm: sha1WithRSAEncryption Issuer: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Validity Not Before: Oct 31 13:57:31 2007 GMT Not After : Oct 28 13:57:31 2017 GMT Subject: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (4096 bit) Modulus (4096 bit):
Уточняем срок действия списка отозваных сертификатов в carevoke.config: #cat carevoke.config |grep default_crl default_crl_days = 365
Создаем пустой пока еще revocation list:
#./createcrl.sh Using configuration from carevoke.config Enter pass phrase for ./ca.key: #ls crl.pem crl.pem #openssl crl -text -in crl.pem |head -10 Certificate Revocation List (CRL): Version 1 (0x0) Signature Algorithm: sha1WithRSAEncryption Issuer: /C=UA/ST=UA/L=Kiev/O=GPAHARENKO-UA/OU=ROOTCA/CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Last Update: Oct 31 14:03:21 2007 GMT Next Update: Oct 30 14:03:21 2008 GMT No Revoked Certificates. Signature Algorithm: sha1WithRSAEncryption #
Далее создавать серверные и клиентские сертификаты можно по следующей схеме. Создается пустая папка. В ней файл openssl.conf с шаблоном сертификата:
#cat SERVERS/sales/openssl.conf [ req ] default_bits = 1024 distinguished_name = req_distinguished_name prompt = no req_extensions = v3_req
[ req_distinguished_name ] C = UA ST = UA L = Kiev O = GPAHARENKO-UA OU = SALES CN = sales.gpaharenko.com.ua emailAddress = gpaharenko@gpaharenko.com.ua
[ v3_req ] basicConstraints = CA:FALSE subjectKeyIdentifier = hash
Если сертификат клиентский, необходимо также указать пароль для закрытых ключей сертфиката в файле pass. По умолчанию в pkcs12 они шифруются DES3. Создадим серверный сертификат:
#./createserver.sh SERVERS/sales/ Generating RSA private key, 1024 bit long modulus .....++++++ ...++++++ e is 65537 (0x10001) writing RSA key CA signing: SERVERS/sales//server.csr -> SERVERS/sales//server.crt: Using configuration from ca.config Enter pass phrase for ./ca.key: Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName :PRINTABLE:'UA' stateOrProvinceName :PRINTABLE:'UA' localityName :PRINTABLE:'Kiev' organizationName :PRINTABLE:'GPAHARENKO-UA' organizationalUnitName:PRINTABLE:'SALES' commonName :PRINTABLE:'sales.gpaharenko.ua' emailAddress :IA5STRING:'gpaharenko@gpaharenko.ua' Certificate is to be certified until Oct 29 14:27:03 2012 GMT (1825 days)
Write out database with 1 new entries Data Base Updated CA verifying: SERVERS/sales//server.crt CA cert SERVERS/sales//server.crt: OK
Серверный сертификат server.crt:
#openssl x509 -text -in SERVERS/sales/server.crt |head -15 Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Validity Not Before: Oct 31 14:27:03 2007 GMT Not After : Oct 29 14:27:03 2012 GMT Subject: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=SALES, CN=sales.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:c6:19:04:81:59:7d:12:b5:fe:f5:6a:cc:13:5b: #
Закрытый ключ серверного сертификта server.key:
#openssl rsa -text -in SERVERS/sales/server.key |head -5 writing RSA key Private-Key: (1024 bit) modulus: 00:c6:19:04:81:59:7d:12:b5:fe:f5:6a:cc:13:5b: 18:ed:30:b0:1f:81:a3:5f:fa:40:8f:47:3f:ff:84: 1a:36:ac:c4:02:88:e5:ce:79:f0:e2:26:e8:86:1e:
После этого можно подготовить архив со всеми необходимыми файлами и передать их системному администратору сервера:
#./bundleserver.sh SERVERS/sales/ #tar -tzf SERVERS/sales/deploy.tar.gz SERVERS/sales//server.crt SERVERS/sales//server.key ca.crt crl.pem #
Аналогично создается клиентский сертификат. Главное не забыть указать пароль, которым будет зашифрован сертификат.
#echo "gpaharenko" > SERVERS/sales/gleb/pass #./createclient.sh SERVERS/sales/gleb/ Generating a 512 bit RSA private key ......++++++++++++ ...................................++++++++++++ writing new private key to 'SERVERS/sales/gleb//client.key' ----- CA signing: SERVERS/sales/gleb//client.csr -> SERVERS/sales/gleb//client.crt: Using configuration from ca.config Enter pass phrase for ./ca.key: Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName :PRINTABLE:'UA' stateOrProvinceName :PRINTABLE:'UA' localityName :PRINTABLE:'Kiev' organizationName :PRINTABLE:'GPAHARENKO-UA' organizationalUnitName:PRINTABLE:'SALES' commonName :PRINTABLE:'gpakharenko' emailAddress :IA5STRING:'gpaharenko@gpaharenko.ua' Certificate is to be certified until Oct 30 14:34:08 2008 GMT (365 days)
Write out database with 1 new entries Data Base Updated CA verifying: SERVERS/sales/gleb//client.crt CA cert SERVERS/sales/gleb//client.crt: OK
Кроме файлов .crt и .key создается файл pkcs12, который, в основном, используется клиентскими программами.
#openssl pkcs12 -info -in SERVERS/sales/gleb/client.p12 Enter Import Password: MAC Iteration 2048 MAC verified OK PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048 Certificate bag Bag Attributes localKeyID: 47 F2 5A 86 BB 3B BF DB BD 5C DA 87 D4 3F 27 59 67 A5 16 B8 friendlyName: my_client_certificate subject=/C=UA/ST=UA/L=Kiev/O=GPAHARENKO-UA/OU=SALES/CN=gpakharenko/emailAddress= gpaharenko@gpaharenko.ua issuer=/C=UA/ST=UA/L=Kiev/O=GPAHARENKO-UA/OU=ROOTCA/CN=ca.gpaharenko.ua/emailAdd ress=gpaharenko@gpaharenko.ua
Упаковуем клиентский сертификат:
#./bundleclient.sh SERVERS/sales/gleb/ #tar -tzf SERVERS/sales/gleb/deploy.tar.gz SERVERS/sales/gleb//client.p12 ca.crt crl.pem #
Одной из важных задач управления жизненым циклом является отзыв сертификата. Выполняется он с помощью скрипта revoke.sh
#./createclient.sh SERVERS/sales/blocked/ Generating a 512 bit RSA private key ...++++++++++++ ............++++++++++++ writing new private key to 'SERVERS/sales/blocked//client.key' ----- CA signing: SERVERS/sales/blocked//client.csr -> SERVERS/sales/blocked//client.crt: Using configuration from ca.config Enter pass phrase for ./ca.key: Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName :PRINTABLE:'UA' stateOrProvinceName :PRINTABLE:'UA' localityName :PRINTABLE:'Kiev' organizationName :PRINTABLE:'GPAHARENKO-UA' organizationalUnitName:PRINTABLE:'SALES' commonName :PRINTABLE:'blocked' emailAddress :IA5STRING:'gpaharenko@gpaharenko.ua' Certificate is to be certified until Oct 31 09:50:04 2008 GMT (365 days)
Write out database with 1 new entries Data Base Updated CA verifying: SERVERS/sales/blocked//client.crt CA cert SERVERS/sales/blocked//client.crt: OK #./revoke.sh SERVERS/sales/blocked/client.crt Using configuration from carevoke.config Enter pass phrase for ./ca.key: Revoking Certificate 03. Data Base Updated Using configuration from carevoke.config Enter pass phrase for ./ca.key: #
Можем убедиться, что в обновленном файле crl.pem содержится сертификат с номером 3:
#openssl crl -text -in crl.pem | head -8 Certificate Revocation List (CRL): Version 1 (0x0) Signature Algorithm: sha1WithRSAEncryption Issuer: /C=UA/ST=UA/L=Kiev/O=GPAHARENKO-UA/OU=ROOTCA/CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Last Update: Nov 1 09:50:26 2007 GMT Next Update: Oct 31 09:50:26 2008 GMT Revoked Certificates: Serial Number: 03 # #openssl x509 -text -in SERVERS/sales/blocked/client.crt | head -4 Certificate: Data: Version: 1 (0x0) Serial Number: 3 (0x3)
#
Краткая справка об инфраструктуре открытых ключей и OpenSSL
Желающим глубоко изучить теорию открытых ключей рекомендую обратиться к книге Брюса Шнайера "Прикладная криптография". Остальным предлагаю бегло напомнить основные понятия.
Существует два основных класса криптографических алгоритмов - симметричные и ассиметричные. В симметричных для шифрования и дешифрования сообщения используется один и тот же ключ. В ассиметричных разные. Тот которым расшифровывают сообщения называется закрытым ключем, ключ для шифрования называется открытым. Поэтому раздел криптографии изучающий свойства открытых ключей получил название криптография открытого ключа. С помощью открытых и закрытых ключей можно подписывать документы. Для этого рядом с ключем сохраняют данные о владельце ключа и полученный файлы называется сертификатом. Вся система взаимотношений между владельцами сертификатов построена на доверии к определенным пользователям. Их подписи общеизвестны, и они подписывают сертификаты других членов, подтверждая тем самым достоверность открытого ключа и хранящихся вместе с ним данных о владельце. Для того что бы система не была скомпрометирована, пользователи принимают только сертификаты с подписями доверенных членов. Приведем более строгую терминологию:
Инфраструктура открытого ключа (PKI) является системой цифровых сертификатов, центров сертификации (ЦС), которая производит проверку и подтверждение подлинности каждой из сторон, участвующих в электронной операции, с помощью криптографии открытых ключей.
Сертификат открытого ключа, обычно называемый просто сертификатом - это документ с цифровой подписью, связывающий значение открытого ключа с удостоверением пользователя, устройства или службы, которым принадлежит соответствующий закрытый ключ.
Центр Сертификации (Certification Authority, CA) является пакетом программного обеспечения, принимающим и обрабатывающим запросы на выдачу сертификатов, издающим сертификаты и управляющим выданными сертификатами.
Корневой сертификат - сертификат принадлежащий Центру Сертификации, с помощью которого проверяется достоверность других выданных центром сертификатов.
Список отозванных сертификатов - список скомпрометированных или недействительных по какой либо другой причине сертификатов.
Отличительное имя (Distinguished Name, DN) - данные о владельце сертификата. Включают CN (Common Name), OU (Organization Unit), O (Organization), L (Locality), ST (State or province), C (Country name).
Электронная цифровая подпись (ЭЦП)- реквизит электронного документа предназначенный для удостоверения источника данных и защиты данного электронного документа от подделки.
Схема электронной подписи обычно включает в себя:
алгоритм генерации ключей пользователя;
функцию вычисления подписи;
функцию проверки подписи.
Функция вычисления подписи на основе документа и секретного ключа пользователя вычисляет собственно подпись. Функция проверки подписи проверяет, соответствует ли данная подпись данному документу и открытому ключу пользователя. Открытый ключ пользователя доступен всем, так что любой может проверить подпись под данным документом.
Для того что бы подписать документ нужно зашифровать с помощью закрытого ключа значение хеш-функции от содержимого документа. Что бы проверить подпись, нужно расшифровать с помощью открытого ключа значение подписи и убедиться, что оно равно хешу подписанного документа. Таким образом цифровая подпись, это зашифрованный хеш документа.
Ключ - это набор параметров (чисел). Он может храниться в файле. В теории клиенты должны сами генерировать свои закрытые и открытые ключи, создавать запрос на подпись открытого ключа и отправлять его в центр. На практике большинство клиентов не умеют генерировать ключи, поэтому в нашем случае Центр осуществляет данную работу. Центр может отзывать сертификат, выданный клиенту, помещая его в черный список, который регулярно передается пользователям центра. С помощью корневого сертификата, который публично доступен, пользователи могут проверять сертификаты друг друга.
Итого у центра сертификации имеется:
закрытый ключ
корневой сертификат (хранящий в себе открытый ключ);
список отозванных (скомпрометированных) сертификатов
У клиентов:
закрытый ключ;
сертификат, подписанный корневым;
корневой сертификат для проверки того, что сертификаты других пользователей выданы его доверенным центром;
список отозванных (скомпрометированных) сертификатов.
Создание корневого сертификата включает:
Генерацию закрытого ключа.
Генерацию открытого ключа и его подпись с помощью закрытого.
Создание обычного сертификата включает:
Генерацию закрытого ключа.
Создание запроса на подпись сертификата.
Подпись запроса в центре сертификации о получение сертификата.
Общепринятый формат информации, содержащейся в сертификате, называется Х509. Сертификаты и ключи могут храниться в разных типах файлов. В нашем случае это будут PEM и PKCS12. PEM используется на серверах, PKCS12 - в браузерах.
OpenSSL - набор криптографических программ и библиотек - предоставляет средства для управления сертификатами и закрытыми ключами. Синтаксис вызова его функций openssl имя_команды параметры. Наиболее часто встречаемые параметры - это -in имя_файла - файл, который обрабатывается, и -text - отобразить информацию о файле в текстовом формате. Основные команды:
| rsa | Работа с ключами |
| x509 | Работа с файлами сертификатов в формате PEM |
| pkcs12 | Работа с файлами сертификатов в формате PKCS12 |
| crl | Работа со списком отозванных сертификатов |
Отобразить информацию о закрытом ключе:
#openssl rsa -text -in ca.key Enter pass phrase for ca.key: writing RSA key: Private-Key: (4096 bit) modulus: 00:c2:3c:f1:e6:56:b6:a6:87:4c:99:56:3f:03:df: 81:04:5b:b3:4a:40:3e:93:71:62:80:e9:3b:01:00: 21:33:91:3c:3f:6a:79:9e:81:97:8b:f4:3a:f0:b4: 9c:af:2f:77:de:43:34:ea:cc:76:e4:ef:c5:25:00: 85:bc:6b:1c:b8:e7:d4:a4:8c:b5:f2:9f:4b:06:f4:
Отобразить информацию о сертификате в формате PEM:
#openssl x509 -text -in ca.crt Certificate: Data: Version: 3 (0x2) Serial Number: b5:b5:a9:0e:3d:ed:fb:24 Signature Algorithm: sha1WithRSAEncryption Issuer: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Validity Not Before: Oct 31 13:57:31 2007 GMT Not After : Oct 28 13:57:31 2017 GMT Subject: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (4096 bit) Modulus (4096 bit): 00:c2:3c:f1:e6:56:b6:a6:87:4c:99:56:3f:03:df: 81:04:5b:b3:4a:40:3e:93:71:62:80:e9:3b:01:00: 21:33:91:3c:3f:6a:79:9e:81:97:8b:f4:3a:f0:b4: 9c:af:2f:77:de:43:34:ea:cc:76:e4:ef:c5:25:00: 85:bc:6b:1c:b8:e7:d4:a4:8c:b5:f2:9f:4b:06:f4:
Детальную информацию Вы можете получить из документации OpenSSL.
Практическое руководство по созданию центра сертификации
Глеб Пахаренко (Gleb Pakharenko), gpaharenko at gmail com
Предварительная подготовка
Данный этап включает оценку числа клиентов, спецификацию требуемых типов сертификатов, требования к их стойкости и времени жизни. На выходе желательно получить предварительные версии Certificate Policy и Certificate Practic. Возможно, это будет один совмещенный документ. В Certificate Policy описываются общая архитектура центра сертификации, ответственные лица, процедуры первоначальной генерации корневого сертификата, резервного копирования, обстоятельства отзыва ключей, механизм передачи сертификатов клиентам (внутренним и внешним). В Certificate Statement описываются типы сертификатов, необходимые атрибуты и расширения, уточнения процедур передачи отзыва, перевыдачи, сроки жизни. Предусмотрите также действия в случае компрометации центра. Желательно систематизировать именование полей сертификатов, к примеру, в качестве OU можно использовать общепринятое название отдела. В Интернете можно найти множество примеров данных документов.
В статье у нас будет только 2 типа сертификатов: клиентский и серверный. Серверный предназначен для аутентификации веб-серверов. Клиентский используется для аутентификации клиента при доступе к веб-ресурсу.
Таким образом, в нашем конкретном случае необходимо ответить на следующее:
длина ключа корневого сертификата;
длина ключа серверного сертификата;
длина ключа клиентского сертификата;
срок действия корневого сертификата;
срок действия серверного сертификата;
срок действия клиентского сертификата;
срок действия revocation list;
сроки проводения резервного копирования и восстановления;
ответственные лица и подразделения компании, связанные с деятельностью центра сертификации;
пароль для корневого сертификата.
Рекомендую выработать общие правила для настройки авторизации X509 и параметров SSL на серверах компании. В документе можно описать разрешенные криптоалгоритмы, версии SSL, глубину верификации цепочки сертификатов, какие данные о сертификате клиента следует отображать в журналах.
Из опыта рекомендую назначить системных администраторов ответственными за внедрение, безопасное хранение, своевременное обновление серверных сертификатов данных серверов. Использование материальных носителей при передаче сертификатов создает избыточную нагрузку на ответственных за выдачу. Как вариант можно использовать разные каналы связи, сертификат по e-mail, пароль по телефону, sms. Большинство пользователей клиентских сертификатов не в состоянии самостоятельно сгенерировать запрос на подпись, поэтому ключи для них нужно создавать самим. При экспорте клиентам нужен файл в pkcs12 формате, администраторам серверов файлы ключа и сертификата в формате PEM. Необходимо следить за временем на машине центра сертификации, т.к. неточность грозит тому, что сертификат может быть недействителен некоторое время после выдачи. Компьютер центра желательно отключить от сети. Передачу сертификатов можно осуществлять на flash-носителе.
скрипт для упаковки необходимых для
Краткое описание файлов:
| bundleclient.sh |
скрипт для упаковки необходимых для отправки клиенту файлов |
|
bundleserver.sh |
скрипт для упаковки необходимых для отправки клиенту файлов |
|
ca.conf |
файл с параметрами корневого сертификата |
|
ca.crt |
корневой сертификат |
|
ca.db.certs |
Каталог, где хранятся выданные сертификаты |
|
ca.key |
закрытый ключ сертификата |
|
ca.pfx |
корневой сертификат в специальном формате |
|
carevoke.config |
файл с параметрами отзыва сертификатов |
|
createca.sh |
скрипт создания корневого сертификата |
|
createclient.sh |
скрипт создания клиентского сертфиката |
|
createcrl.sh |
скрипт создания списка отозваных сертификатов |
|
createserver.sh |
скрипт создания серверного сертификата |
|
crl.pem |
список отозваных сертификатов |
|
revoke.sh |
скрипт отзыва сертификата |
|
sign1.sh |
Скрипт, подписывающий серверные сертификаты |
|
signclient.sh |
Скрипт, подписывающий клиентские сертификаты |
В каталоге, в котором будет лежать серверный сертификат, необходимо поместить файл с параметрами openssl.conf.
В каталоге, в котором будет лежать клиентский сертификат, необходимо поместить файл с параметрами openssl.conf и файл с паролем pass.
Ссылки
Кори Хайнс (Corey Hynes). Введение в Инфраструктуру открытого ключа (PKI, Public Key Infrastructure) и Службы сертификации (Certificate Services) Windows Server 2003
Инфраструктура открытого ключа. Сайт Microsoft TechNet.
Red Hat Certificate System. Administrator's Guide
Электронная цифровая подпись. Материал из Википедии
Предполагаемой аудиторией статьи являются работники
Предполагаемой аудиторией статьи являются работники служб информационной безопасности.
В данной статье рассмотрены детали построения и сопровождения собственного центра сертификации на основе OpenSSL. Вопросы установки программного обеспечения не затрагиваются. Решение в виде набора скриптов легко создается без значительных затрат, что позволяет обслуживать порядка сотни клиентов со сроком действия сертификата, измеряемом в годах. Предполагается, что клиенты однообразны и их количество изменяется достаточно медленно.
При числе клиентов более тысячи, разнообразии приложений, которым требуются сертификаты, необходимо использовать проприетарное решение. Большинство известных вендоров предлагают качественные продукты для управления жизненным циклом сертификатов. Альтернативой OpenSSL является построение центра сертификации на основе служб Windows.
К созданию центра сертификации необходимо
К созданию центра сертификации необходимо отнестись с большой ответственностью, особенно в случаях, когда сертификаты выдаются партнерам компании. Пересоздание корневого сертификата может повлечь за собой отзыв старых и выдачу новых сертификатов клиентам, или необходимость поддерживать несколько сертификатов доверенных центров в системах, что вызывает дополнительную нагрузку на администрирующий персонал. Желательно как можно полнее отразить процессы жизненного цикла сертификатов в формальных документах. Незатронутой осталась тема продления корневого сертификата, т.к. при задании ему достаточно большого срока жизни, эта проблема не является актуальной. Следует внимательно отнестись к физической охране сервера сертификации и обеспечить доступ к нему только узкому кругу ответственных лиц. Для улучшения защиты можно использовать шифрование файловой системы, где развернуты файлы центра.
Необходимо подчеркнуть, что текущий набор скриптов и конфигурационных файлов можно доработать, чтобы параметры сертификатов находились только в конфигурационных файлах и уменьшилось дублирование информации.
Проверка алгоритмов асимметрического шифрования:
Подписывание Проверка За секунду подп. За секунду пров. rsa 512 bits 0.0036s 0.0003s 281.4 3221.7 rsa 1024 bits 0.0184s 0.0009s 54.3 1072.9 rsa 2048 bits 0.1105s 0.0032s 9.0 315.6 rsa 4096 bits 0.7414s 0.0112s 1.3 89.4
dsa 512 bits 0.0032s 0.0038s 311.3 261.3 dsa 1024 bits 0.0093s 0.0116s 107.5 86.4 dsa 2048 bits 0.0309s 0.0377s 32.4 26.5
Результат работы тестов скорости
Алгоритм 8 байт 64 байта 256 байт 1024 байта 8192 байт
md2 291.38k 817.15k 1109.67k 1218.56k 1256.11k mdc2 868.57k 911.02k 914.01k 915.11k 917.50k md4 4417.91k 24808.28k 51404.97k 70189.40k 78168.06k md5 3905.61k 21142.91k 41515.69k 55489.54k 59091.63k hmac(md5) 1536.42k 10381.81k 27585.13k 46119.35k 57671.68k sha1 2458.59k 11965.97k 21560.58k 26889.22k 29143.66k rmd160 2032.99k 9523.48k 16568.15k 20547.81k 22220.11k rc4 28775.08k 39239.02k 41210.52k 41862.98k 41454.25k des cbc 7586.90k 8411.44k 8580.28k 8627.29k 8612.52k des ede3 2866.13k 3031.96k 3050.92k 3074.74k 3058.35k idea cbc 4948.09k 5743.19k 5760.09k 5744.67k 5723.48k rc2 cbc 2982.04k 3220.39k 3256.32k 3263.49k 3268.61k rc5-32/12 cbc 19108.39k 24151.19k 24906.75k 25154.90k 25212.25k blowfish cbc 11018.91k 12881.27k 12925.01k 12972.37k 13047.13k cast cbc 10943.48k 12674.30k 12877.74k 12994.56k 13011.63k
