|
Bog BOS: Безопасность |
|
Последние изменения: |
Последнее изменение файла: 2009.08.20
Скопировано с www.bog.pp.ru: 2024.11.23
Цели обеспечения безопасности передачи и хранения данных:
При симметричном шифровании один и тот же ключ используется как для шифрования, так и для дешифрования сообщения. Существуют прикидки, что для поиска 256-битного ключа методом полного перебора не хватит энергии всей нашей галактики при ее оптимальном использовании. Для реальных задач достаточно 128 бит.
Режимы могут быть с зависимостью от состояния (statefull) и без зависимости (stateless). Шифрование данных на носителе можно рассматривать как посылку самому себе в будущее, при этом состояние хранить негде и допустимы только stateless режимы. Начальный вектор не хранится и извлекается из номера сектора, схема шифрования должна учитывать предсказуемость начального вектора. Некоторые режимы (CFB, OFB, CTR) требуют уникальности начального вектора для каждого блока. Начальный вектор может называться:
Рекомендуемый метод получения начального вектора для CBC и CFB - датчик случайных чисел или зашифрованный счётчик. Для OFB достаточно использовать счётчик.
При использовании CBC для шифрования носителя данных каждый сектор шифруется отдельно и требует отдельного начального вектора:
Используется пара ключей: открытый (public) ключ получателя для шифрования сообщения и секретный (private) ключ получателя для дешифрования.
Стойкость современных алгоритмов основывается на недоказанном математическом предположении о сложности разложения больших чисел на множители (факторизации) (RSA) или дискретного логарифмирования в конечных полях (Эль Гамаль, DSA), хотя и опровержения (пока?) нет. Рекомендуемая длина ключа для алгоритмов, основанных на разложении числа на множители, составляет 2048 бит при необходимости долговременного хранения (при условии, что не будет найдет кардинально более быстрый алгоритм разложения), для кратковременного хранения - 1280 бит. Для DSA требуется меньшая длина ключа.
Асимметричные алгоритмы работают значительно медленнее симметричных (в тысячи раз!) и уязвимы относительно атаки со знанием открытого текста, поэтому обычно используются только для согласования случайного разового ключа для дальнейшего симметричного шифрования. Это также упрощает рассылку сообщения группе получателей (достаточно зашифровать только сеансовый ключ открытым ключом каждого получателя, а само сообщение шифруется отлько один раз).
Криптографически стойкие контрольные суммы (MAC, хеш, дайджест) |
Необходимы для проверки целостности данных (при современных скоростях и объемах CRC-32 уже недостаточно) и цифровой подписи. Используются также для упрощения визуального сравнения открытых ключей (fingerprint). Криптографическая стойкость означает трудоемкость модификации сообщения с сохранением контрольной суммы (или генерация сообщения, порождающего указанную контрольную сумму). В частности, длина контрольной суммы не должна быть менее 128 бит (а лучше 160).
Контрольная сумма может рассчитываться после шифрования (encrypt-then-mac), до шифрования (mac-then-encrypt, не рекомендуется) или одновременно (encrypt-and-mac, запатентованы - IAPM, OCB, XECB).
HMAC (RFC 2104, Hash Message Authentication Code) - применение любой криптографически стойкой контрольной суммы (не менее 128 бит, HMAC-MD5, HMAC-SHA1) к некоторому сочетанию хеша разделяемого ключа, сообщения и ключа. Длина ключа д.б. не менее длины хеша. Если длина ключа больше длины блока алгоритма хеширования, то вместо ключа используется его хеш. Желательно использование в качестве ключа случайного значения и регулярная смена. Передаётся вместе с сообщением.
Английское слово из 10 букв содержит всего 12 бит энтропии, а надо 128 или 256! Программным путём нельзя увеличить количество энтропии в парольной фразе, но можно искусственно затруднить (в вычислительном смысле) полный перебор, а именно сделать преобразование парольной фразы в ключ вычислительно сложным. Чтобы избежать возможности заранее просчитать все возможные варианты ключей в исходные параметры преобразования включают случайную строку (соль) достаточной длины, хранится в открытом виде, так что запоминать её не надо.
Стандарт PBKDF1 преобразования парольной фразы в ключ. Устарел.
Стандарт PBKDF2 (RFC 2898; password-based key derivation function, revision 2) преобразования парольной фразы в ключ использует большое (не менее 1000) количество итераций функции хеширования, совмещая промежуточные результаты с помощью XOR (чтобы избежать возможной дегенерации энтропии). Соль - не менее 64 бит случайных данных.
Стандарт PKCS #5 (RFC 2898) определяет метод получения ключа из парольной фразы (алгоритмы - PBKDF2 для новых приложений и PBKDF1 для совместимости со старыми, и дополнительно предназначение ключа), схемы шифрования (PBES2 для новых приложений - PBKDF2 в сочетании с каким-либо алгоритмом симметричного шифрования; PBES1 для совместимости со старыми - PBKDF1 в сочетании с DES-CBC и RC2-CBC), аналогичные схемы для обеспечение целостности (PBMAC - сочетание PBKDF2 и какого-либо алгоритма криптостойкого хеширования) и синтаксис (ASN.1) для названия схемы. Практика (PKCS #5): HMAC-SHA-1 для обеспечения целостности; DES-CBC-Pad, DES-EDE3-Pad, RC5-CBC-Pad для шифрования.
Для подписания документа отправитель шифрует его секретным ключем (на практике, для экономии времени шифруется контрольная сумма документа, что также позволяет поставить несколько подписей), получатель может дешифровать его (ее) с помощью открытого ключа отправителя. Подписанный документ может быть дополнительно зашифрован открытым ключом получателя (но нельзя подписывать зашифрованные сообщения - получатель может предложить "вредный" открытый ключ). Пары ключей для подписи и шифрования могут быть различными, хотя распространенные ассиметричные алгоритмы позволяют использовать одну и ту же пару для обеих целей (это уменьшает стойкость протокола).
Кроме протокола цифровой подписи требуется определить процедуру разбора конфликтных ситуаций (арбитр запращивает секретный ключ и определяет виновного: подписант, получатель или центр сертификации открытых ключей).
Последовательность чисел является случайной, если ее элементы нельзя предсказать. Программным путем можно получить только псевдослучайные числа. Качество генератора случайных чисел очень важно, так как сеансовые ключа получаются на его основе и если злоумышленик может предсказать следующее "случайное" число, то он сможет расшифровать данные.
RFC 1750.
PRNG, одобренный FIPS (FIPS 186, appendix 3).
ANSI X9.17 "Financial Institution Key Management (Wholesale)", appendix C.
Сертификаты позволяют сопоставить открытый ключ и его владельца (человека или сервера). Выдается и подписывается бюро сертификации (CA - certificate authority). Для проверки сертификата требуется открытый ключ CA, открытые ключи основных коммерческих CA (да, да! получение сертификата требует денег!) "зашиты" в прикладной программе (например, браузере) или могут быть добавлены в список CA вручную. Необходим, чтобы помешать взломщику отправить клиенту фальшивый открытый ключ от имени сервера (или фальшивый ключ от имени клиента серверу). В общем случае, в цепочке сертификатов от общедоверительного сертификатора CA до проверяемого сертификата может быть множество звеньев. Все допустимые цепочки образуют дерево (иерархическая модель доверия) или сеть доверия (например, используется в PGP). Наиболее употребимый стандарт формата сертификатов - ITU-T X.509 версия 3 (RFC 2459, ANSI X9.55, PKCS 6).
Стандарты инфраструктуры сертификатов:
PKCS #6 определяет формат сертификатов (расширение X.509v3):
PKCS #10 (RFC 2986, Certification Request Syntax Specification) определяет формат запроса на подпись сертификата, направляется клиентом, создавшим сертификат, к CA на получение подписи. PKCS #9 определяет дополнительные атрибуты запроса на подпись сертификата:
Формат обмена сертификатами см. ниже.
Самые известные коммерческие CA: Verisign (прославился выдачей фальшивого сертификата для Microsoft) и Thawte. Для внутренних нужд можно использовать частное CA.
Предусмотрены средства отзыва (revoking, аннулирование) скомпрометированных сертификатов CRL (Certificate Revocation List) и протокол проверки состояния сертификата OCSP (Online Certificate Status Protocol).
Если сертификат подписывается личным ключом, соответствующим открытому ключу, содержащемуся в сертификате, то такой сертификат называется самоподписанным.
Методика создания поддельного сертификата: создаётся собственный CA с красивым именем; запускается честный сервер, открытый ключ которого заверен этим CA; при входе на сервер пользователя извещают о неизвестном CA, подписавшем ключ и спрашивают, а не добавить ли его в список допустимых CA; если пользователь действительно хочет посетить сайт, то он ответит "да"; теперь при заходе на фальшивый сайт "www.superbank.com" браузер молча воспримет фальшивый открытый ключ, заверенный злонамеренным CA как ключ для "www.superbank.com".
Ключи необходимо создавать (например, преобразуя парольную фразу или используя генератор случайных чисел), хранить, распространять, проверять подлинность, отзывать, депонировать. Алгоритмы согласования ключей:
Протоколы работы с ключами:
PKCS #8 (Private-Key Information Syntax Standard) определяет формат обмена частными ключами. Кроме самих ключей (возможно зашифрованных по одному из алгоритмов PKCS #5, RFC 2898) может включаться дополнительная информация (определяется в PKCS #9). Формат описывается на ASN.1, т.е. получаются двоичные файлы.
PKCS #9 (Selected Object Classes and Attribute Types, RFC 2985, ISO/IEC 9594-6) определяет перечень и описание дополнительных атрибутов, включаемых в передаваемую информацию. Совокупность атрибутов оформляется в виде одного из 2 классов объектов: pkcsEntity и naturalPerson (информация о человеке). Атрибуты для naturalPerson:
PKCS #12 (Personal Information Exchange Syntax Standard) определяет формат передачи персональной информации (сертификаты (X.509, SDSI), частные ключи, CRL, атрибуты согласно PKCS #9). В терминологии MS формат называется PFX. Формат описывается на ASN.1, т.е. получаются двоичные файлы. Информация может быть защищена от чтения шифрованием публичным ключом получателя (разовый ключ шифруется RSA, информация шифруется разовым ключом) или паролем (парольная фраза, соль, число итераций, RC4-40, RC4-128, 3DES-CBC, RC2-40, RC2-128). Информация может быть защищена от подделки цифровой подписью на основе частного ключа отправителя (получатель должен иметь соответствующий публичный ключ) или паролем (может отличаться от пароля шифрования, SHA-1 HMAC). Транспортные ключи не имеют никакого отношения к ключам, передаваемым внутри сообщения. Дополнительные атрибуты согласно PKCS #9:
Генераторы паролей:
Ключи и сертификаты могут кодироваться в двоичном формате в соответствии с DER (Distinguished Encoding Rules), подмножеством BER (Basic Encoding Rules), описанном по правилам ASN.1. Двоичный формат может быть преобразован в ASCII с помощью кодировки Base64. Дополненный заголовками вида "BEGIN CERTIFICATE" текстовый формат называется PEM (Privacy Enhanced Mail).
SSL (Secire Sockets Layer) - протокол (разработан и предложен Netscape), обеспечивающий аутентификацию сервера, аутентификацию клиента, шифрование данных, целостность данных. Принят как IETF стандарт под именем TLS (Transport Layer Security, RFC 2246). Обеспечивает возможность повторного подключения без повторной аутентификации и согласования ключей сеанса. Обеспечивается согласование допустимых алгоритмов генерирования ключей (DH), шифрования (3DES-CBC, RC2, RC4, IDEA, DES, Triple-DES, AES, Blowfish), цифровой подписи и аутентификации (DSS, RSA, анонимный доступ с последующей дополнительной аутентификацией), хеширования (SHA-1, MD5). Действует как промежуточный протокол между TCP и прикладным протоколом либо с помощью выделенного порта (TCP/443 для https: в случае HTTP; TCP/993 или TCP/585 для IMAP), либо дополнительных команд протокола (STARTTLS для SMTP). Сервер отправляет сертификат, подписанный известным клиенту CA и содержащий открытый ключ сервера. Зная сертифицированный открытый ключ сервера, клиент модет убедиться в подлинности сервера по его цифровой подписи. Для дешифрования сертификата и проверки цифровой подписи используется алгоритм RSA для установления сеанса. Далее клиент генерирует и передает разовый случайный ключ (шифруя его открытым ключом сервера), которым в дальнейшем шифруется сеанс с помощью симметричного алгоритма шифрования (это очень упрощённое описание, в действительности, на основе случайных чисел со стороны клиента и сервера и предварительного случайного ключа создаётся целая связка ключей, используемых для различных целей: клиентский ключ, серверный ключ, ключ хеширования клиента, ключ хеширования сервера и т.д.). Протокол включает возможность аутентификации не только сервера, но и клиента (заверенный CA сертификат, содержащий открытый ключ и зашифрованное личным ключом случайное число, полученное от сервера), но чаще используется обычная связка имя-пароль под защитой зашифрованного SSL-соединения. SSL3/TLS дополнительно использует вычисление контрольных сумм для проверки целостности передачи данных. SSL2 имеет известные дефекты и пользоваться им не рекомендуется. Наследием тяжёлого прошлого являются слабые алгоритмы шифрования с 40-битовым ключом, включённые в общий список допустимых алгоритмов.
Свободно распространяемой реализацией является OpenSSL. Используется в OpenSSH, HTTP сервере Apache, почтовом сервере Exim, MySQL.
Под VPN (Virtual Private Network, виртуальная частная сеть) здесь понимаются технологии построения защищенных каналов между сетями поверх общедоступной сети (TCP/IP). Канал в данном случае является шифрованным туннелем между конечными точками (шлюзами VPN). Можно также рассмотривать каналы между хостом и сетью и между отдельными хостами. Многие технологии VPN в дополнение к шифрованию обеспечивают аутентификацию (целостность) сообщений. Передача по каналу между сетями прозрачна для конечных пользователей и не требует изменений в прикладных протоколах. Объединение сетей есть объединение областей доверия, а VPN не защищает точки входа. Для их защиты и ограничения трафика между сетями необходимо использовать сетевой экран (например, iptables). Сетевой экран может быть установлен на том же компьютере, что и VPN шлюз (плохо масштабируется); параллельно ему (больше работы); между шлюзом и Интернет (VPN поток проходит дважды по локальной сети).
|
Bog BOS: Безопасность |
|
Последние изменения: |