Для обеспечения секретности в подавляющем большинстве случаев используются методы криптографии. Современные алгоритмы шифрования при условии обеспечения секретности ключа предоставляют возможность защиты даже от таких противников, как правительственные агентства. Однако существуют ситуации, когда секретность одних и тех же данных должна обеспечиваться только при попытке выполнения запрещенных действий, а в остальных случаях доступ к данным должен быть свободным.
Защита содержимого DVD-дисков DVD-диски с кинофильмами могут быть записаны для какого-то определенного региона (Северная Америка, Европа и т. д.) и должны без проблем воспроизводиться на проигрывателях этого региона. Но диск, купленный в США, не должен воспроизводиться на DVD-проигрывателе, купленном в Европе. Также не должно быть возможным извлечение содержимого диска на персональном компьютере. Однако интуитивно понятно, что если данные на DVD-диске зашифрованы и какой-то DVD-проигрыватель может их воспроизвести, значит, диск вместе с проигрывателем содержат достаточно информации для расшифровки содержимого диска. Отсюда следует вывод, что ключ шифрования присутствует в системе, а значит, выполнив те же действия, что выполняет DVD-проигрыватель, можно расшифровать содержимое диска. Получается, что криптография не способна обеспечить секретность в таких сложных условиях, и защиту приходится основывать на запутывании процесса извлечения содержимого диска. Стоит заметить, что для DVD-дисков задача защиты пока так и не была решена эффективно.
С непреднамеренными нарушениями целостности, возникающими из-за ошибок при передаче данных по каналам связи или сбоев при чтении носителей информации, можно бороться путем добавления избыточности к за щищаемой информации, что позволит обнаружить и иногда даже исправить случайно возникающие ошибки. Для этого существует целая теория помехоустойчивого кодирования. В большинстве современных архиваторов (программ для сжатия данных) для контроля целостности распакованного файла используется алгоритм CRC32 (Cyclic Redundant Code, 32-разрядный циклический избыточный код). Перед упаковкой файла для него вычисляется значение CRC32, которое сохраняется вместе со сжатыми данными в архиве. После распаковки снова вычисляется CRC32, и если вычисленное значение не совпало с сохраненным в архиве, файл признается поврежденным. Однако для защиты от умышленного внесения изменений данный метод не подходит — противнику не составит большого труда подкорректировать данные, вычислить от них CRC32 и сохранить исправленные версии в архиве. Даже если противник не имеет возможности исправлять контрольную сумму, использовать CRC32 для защиты не стоит, т. к. этот алгоритм является обратимым — изменением всего четырех байт в файле можно добиться любого нужного значения CRC32.
Поэтому для зашиты от нарушений целостности целесообразно использовать стойкие криптографические хэш-функции (hash function), предотвращающие внесение изменений в защищаемые данные, вместе с шифрованием, препятствующим подмене значения хэш-функции. Для этих целей можно использовать шифрование как с секретным, так и с открытым ключом. При идентификации, как правило, не возникает особенных сложностей: пользователь предъявляет свой идентификатор, а система принимает его. Идентификатором может являться вводимое с клавиатуры имя пользователя, информация, содержащаяся на магнитной полосе пластиковой карты или в памяти смарт-карты, или какой-либо биометрический показатель (отпечаток пальца, форма руки, голос, рисунок радужной оболочки глаза и т. д.). Но почти всегда сразу за идентификацией следует аутентификация, т. к. корректность идентификатора, за исключением биометрического, не гарантирует, что он предъявлен владельцем, а не неким посторонним лицом.
Аутентификация заключается в том, что пользователь, предъявивший идентификатор, вводит некоторую, известную только ему, секретную информацию, которая после некоторого преобразования передается проверяющей стороне. Это может быть пароль, PIN-код (Personal Identification Number, персональ- ный идентификационный номер) и т. п. Проверяющая сторона на основе имеющейся у нее информации (хэша пароля, зашифрованного значения PIN- кода) принимает решение об аутентичности (подлинности) пользователя. Правильное решение задач идентификации и последующей аутентификации включает в себя решение нескольких подзадач.
П Обеспечить невозможность успешного повторения идентификации и аутентификации путем перехвата сетевого трафика и повторной отсылки правильных ответов. Для этого используется схема запрос/ответ (challenge/response), когда проверяющая сторона присылает некоторый случайный запрос (challenge), который используется при аутентификации для преобразования введенных пользователем данных перед отправкой их проверяющей стороне. При таком подходе перехват сетевого трафика оказывается бесполезным — проверяющая сторона каждый раз присылает новый запрос, на который существует единственный правильный ответ, который невозможно быстро вычислить, не зная секретной информации (пароля или PIN-кода). Аутентификация сетевых подключений в Windows 95/98 5 января 1999 года компания LOpht опубликовала статью о найденной уязвимости в реализации схемы запрос/ответ при подключении сетевых ресурсов Windows 95/98. Как оказалось, при попытках подключения Windows 95/98 посылает один и тот же запрос в течение примерно 15 минут, и за это время противник может подключиться к сетевому ресурсу от имени того пользователя, чью попытку аутентификации удалось перехватить. П Обеспечить невозможность эффективного получения секретной информации, вводимой пользователем при аутентификации, в случае взлома проверяющей стороны. Для этого проверяющая сторона должна хранить не копию секретной информации, вводимой пользователем, а результат применения к ней стойкой криптографической хэш-функции. Хэши паролей для LANMAN-аутентификации В таких операционных системах, как Windows NT/2000, могут храниться две версии хэшей пароля. Одна версия используется собственными средствами безопасности Windows NT, а другая нужна для обеспечения совместимости с протоколом аутентификации LANMAN, применяемым, в частности, в Windows 95/98.
Собственный хэш Windows NT достаточно стойкий, и по значению хэша практически невозможно найти пароль, использующий цифры, буквы в разных регистрах и знаки препинания и имеющий длину более 8 символов. Однако процедура вычисления хэша LANMAN имеет несколько особенностей, которые значительно ослабляют уровень защиты. При вычислении хэша LANMAN-пароль, длина которого не должна превышать 14 символов, разбивается на 2 части по 7 символов, и хэш для каждой части вычисляется отдельно. Таким образом, при подборе пароля максимальная длина проверяемых слов составляет всего 7 символов, что делает возможным даже полный перебор всех вариантов пароля. Если пароль не длиннее 7 символов, то вторая часть остается пустой и порождает всегда одно и то же значение хэша.
Это позволяет по второй половине хэша сразу определить пароли, которые короче 8 символов. Так как обе части пароля обрабатываются независимо, для паролей длиной от 8 до 12 символов вторая часть может быть найдена максимум перебором всех пятисимвольных комбинаций, что не займет очень много времени. Иногда знание окончания пароля позволяет угадать все слово. Перед вычислением хэша все буквы пароля переводятся в заглавные, что примерно в 9,4 раза сокращает количество возможных комбинаций (при использовании всех символов ASCII). Функция вычисления хэша LANMAN не использует подмешивание "соли" (salt) — случайной несекретной величины, делающей значение хэша уникальным для каждого пользователя, даже если пароли совпадают. Эта особенность позволяет тратить на подбор пароля для любого числа пользователей практически одинаковое время, т. к. на каждого дополнительного пользователя добавляется лишь одна операция сравнения, которая выполняется в тысячи раз быстрее, чем вычисление хэша. После того как по хэшу LANMAN подобран пароль, можно за короткое время подобрать и пароль NT, если его длина не превышает 14 символов. На это по- требуется не более 2 м вариаций прописных и строчных букв, т. е. не более 16 384 комбинаций.
• Минимизировать вероятность ошибок первого рода (отказ в доступе легитимному пользователю) и второго рода (предоставление доступа пользователю, не имеющему на это права). При использовании биометрики для идентификации и/или аутентификации ошибки первого и второго рода играют значительную роль, т. к. биометрика при оценке степени совпадения измеренной биофизической характеристики и ранее сохраненного ее значения опирается на статистические методы. Если при настройке верификатора ослабить требования к точности совпадений, нелегальному пользователю будет легче случайно проникнуть в систему.
Если же требования к точности совпадения повысить, легальные пользователи достаточно часто будут получать отказ в доступе. Хорошо настроенная система идентификации по отпечаткам пальцев необоснованно отказывает в доступе примерно в одном случае из 50 и ошибочно пропускает одного нелегального пользователя из миллиарда. Плюсы и минусы биометрических систем идентификации В качестве достоинств биометрических систем называют, прежде всего, то, что только биометрика аутентифицирует именно человека, а не пароль или устройство вроде смарт-карты. При этом биометрический идентификатор ничего не стоит пользователю, и его нельзя забыть, потерять или передать другому лицу. Правда, сами биометрические системы пока довольно дороги, и их точность может зависеть от психофизического состояния человека (влажность кожи, охрипший голос, неустойчивый почерк из-за травмы руки и т. д.).
Но существует еще один аспект использования биометрики, который является обратной стороной невозможности потерять биометрический идентификатор и о котором часто забывают. Если учетная запись некоторого пользователя оказалась скомпрометирована (например к ней подобрали пароль), сменить пароль или создать новую учетную запись не составит большого труда. Если же по какимто причинам оказался скомпрометирован биометрический идентификатор (на- пример кто-то научился подделывать голос или отпечатки пальцев), у владельца этого идентификатора нет никакой возможности его сменить.
Биометрика может применяться либо для идентификации совмещенной с аутентификацией, либо только для аутентификации. При первом подходе снятая биометрическими методами характеристика сравнивается с учетными записями всех пользователей, зарегистрированных в системе, и если точность совпадения превышает установленное значение, пользователь считается идентифицированным и аутентифицированным. Второй подход требует предоставления идентификатора (имени пользователя, пластиковой карты), а биометрические методы лишь подтверждают его аутентичность. Этот способ хоть и является менее удобным для пользователей, имеет несколько преимуществ. Во-первых, требуется сравнить снятую характеристику только с одним сохраненным значением, а не со всеми. Это может оказаться очень существенным, когда число зарегистрированных пользователей измеряется тысячами. А во-вторых, при наличии традиционного идентификатора гораздо проще пресекать многократные попытки входа в систему нелегального пользователя — достаточно ввести ограничение на максимальное количество попыток входа одного пользователя за фиксированный период времени (например 3 раза в течение 5 минут).
Если же явно выраженный идентификатор отсутствует, можно ограничивать только интенсивность попыток идентификации на одном рабочем месте, но в некоторых случаях (например на проходной большого завода) это нецелесообразно. При решении таких задач информационной безопасности, как уполномочиниы, контроль доступа и обеспечение права собственности, не требуется что-либо защищать. Права доступа к различным объектам определяются формальными правилами в соответствии с используемой моделью управле- ния доступом. Существует две основных модели разграничения доступа: мандатная и дискреционная. Мандатное разграничение доступа заключается в том, что компьютерные ресурсы разделяются на группы в соответствии с уровнями их конфиденциальности. Каждому ресурсу присваивается классификационная метка, задающая назначенный ему уровень.
Полномочия пользователя задаются максимальным уровнем конфиденциальности информации, доступ к которой ему разрешен. В соответствии с этим разрешается доступ только к данным, уровень секретности которых не выше уровня полномочий пользователя. Дискреционное управление доступом — это метод ограничения доступа к компьютерным ресурсам, основанный на учете прав пользователя или группы, в которую этот пользователь входит. Использование данной модели позволяет для каждого пользователя или для каждой группы пользователей явно задать полномочия, указав список ресурсов (логические диски, элементы файловой структуры, порты ввода-вывода и т. д.), к которым разрешен доступ, а также права доступа к этим ресурсам. Один из видов полномочий дает пользователю возможность передать права доступа любому другому пользователю или группе. Существуют и иные виды разграничения доступа, не попадающие ни под мандатную, ни под дискреционную модель. Но подробное рассмотрение систем разграничения доступа выходит за рамки книги. Задачи сертификации в настоящее время встречаются повсеместно, и для решения этих задач используется криптография с открытым ключом.
При выдаче сертификата удостоверяющая сторона гарантирует, что содержимое сертификата является подлинным и может быть использовано при выполнении условия правильности сертификата. Чаще всего сертификаты выдаются на открытые ключи и исполняемые файлы. При использовании криптографии с открытым ключом большой проблемой является доверие к подлинности открытого ключа адресата. Сам открытый ключ может быть создан любым человеком, и если он получен не из стопроцентно безопасного источника (например лично из рук адресата), нельзя быть полностью уверенным в том, что это не подделка, выполненная противником. Использование сертификатов открытых ключей позволяет решить эту проблему. Достаточно иметь один или несколько так называемых корневых сертификатов — сертификатов открытых ключей, принадлежащих базовым удостоверяющим-центрам и подлинность которых может быть проверена множеством способов. Корневой сертификат может быть использован для удостоверения подлинности другого открытого ключа, доверие к которому будет основываться на доверии к базовому удостоверяющему центру, а не к источнику получения ключа.
Сертификация также может быть выполнена цепочкой удостоверяющих центров, что не снижает доверия к сертифицируемому открытому ключу, если, конечно, ни один из центров сертификации, участвовавших в цепочке, не был скомпрометирован. Сертификация исполняемых файлов позволяет подтвердить, что файл был создан именно разработчиком, которому принадлежит сертифицирующий ключ. Это является своеобразной гарантией безопасности: если при использовании сертифицированного исполняемого файла возникают проблемы, всегда можно найти, к кому обращаться с вопросами. А в некоторых случаях разрешено использование исключительно сертифицированных модулей. Так, например, любой криптопровайдер (Cryptographic Service Provider, CSP — модуль, отвечающий за поддержку криптографических функций через стандартный программный интерфейс), используемый в современных версиях Windows, должен быть предварительно сертифицирован компанией Microsoft. КЛЮЧИ RSA в библиотеке ADVAPI32.DLL В январе 2003 года в конференции fido7.ru.crypt появилось сообщение, касающееся процедуры подписания криптопровайдеров в Windows. В сообщении утверждалось, что отсутствие желания каждый раз обращаться в Microsoft и тратить несколько дней на подписание разрабатываемого модуля подтолкнуло к поиску более эффективного решения.
Это решение заключалось в факторизации (разложении на простые сомножители) модуля 512-битового ключа RSA, используемого при проверке подписи и хранящегося в библиотеке ADVAPI32.DLL. По утверждению автора сообщения для факторизации потребовалось чуть больше двух месяцев. Вычисления выполнялись на кластере из 10 машин с процессорами Pentium-III, работающими на частотах от 500 до 1200 МГц. Однако строгих доказательств выполненной факторизации, похоже, опубликовано не было. На самом деле, в библиотеке ADVAPI32.DLL операционных систем семейства NT (Windows NT, 2000 и ХР) находится не один, а целых три RSA-ключа, замаскированных одинаковым образом. Два из них имеют длину 1024 бита, а один действительно 512 бит. Кстати, в 1999 году один из разработчиков компании Cryptonym, анализируя отладочную информацию из Service Pack 5 для Microsoft Windows NT 4, обнаружил символьные метки для двух ключей. Одна из меток называлась "KEY", а другая — "NSAKEY", что недвусмысленно дает понять, кто является владельцем второго ключа. Подпись, как и сертификация, реализуется средствами криптографии с открытым ключом.
Обычно подписанию подвергаются документы, но подпи- сывать можно что угодно, в том числе и исполняемые файлы. Отличие от сертификации здесь в том, что при подписи подтверждение подлинности берет на себя сам автор, а при сертификации гарантии и ответственность ложатся на плечи более высокой инстанции. Подписание модулей расширения для программ семейства Adobe Acrobat Программы семейства Adobe Acrobat имеют возможность подключать модули расширения (plug-ins), предназначенные для увеличения функциональности. Чтобы модуль расширения мог быть загружен в программу Adobe Acrobat Reader, он должен быть подписан разработчиком. А в некоторых режимах, сопряженных с поддержкой DRM (Digital Rights Management, управление цифровыми правами), разрешается загрузка только модулей, сертифицированных и подписанных компанией Adobe. Однако исследователями компании EfcomSoft было установлено, что при проверке сертификата модуля расширения участвуют только некоторые поля заголовка переносимого исполняемого файла, что дает возможность вносить в файл изменения, не нарушающие целостность сертификата.
Это приводит к возможности коррекции исполняемого кода таким образом, чтобы модуль расширения начал выполнять любые действия, включая опасные. Описание данной уязвимости было опубликовано CERT (Computer Emergency Response Team, бригада неотложной компьютерной помощи), и Adobe обещала устранить дефект в еще не вышедшей на тот момент версии Acrobat Reader 6. Но Acrobat Reader 6 уже вышел, и он продолжает загружать модули расширения, подписанные разработчиками старым уязвимым способом. Решение таких задач, как неотказуемость, расписка в получении, свидетельствование и датирование, тесно связано с решением задач сертификации и подписи и тоже обеспечивается методами асимметричной криптографии. Аннулирование заключается в обновлении списков отозванных сертификатов (Certificate Revocation List, CRL) и списков отмены удостоверяющих центров (Authority Revocation List, ARL).
Самым сложным здесь является необходимость обеспечить регулярную и своевременную доставку списков отмены до того, как скомпрометированный ключ будет применен со злым умыслом. Компрометация сертификатов Microsoft Corporation 30 и 31 января 2001 года удостоверяющий центр компании VeriSign выдал два цифровых сертификата лицу, выдавшему себя путем обмана за работника компании Microsoft. Эти сертификаты могут быть использованы для подписания компонентов ActiveX, макросов Microsoft Office и других исполняемых модулей. VeriSign добавил эти сертификаты в свой список отозванных сертификатов сразу же после обнаружения обмана. Но сертификаты, выпускаемые VeriSign для подписания исполняемого кода, не содержат указания на центр распространения списков отмены (CRL Distribution Point, CDP). Из-за этого программное обеспечение Windows не способно автоматически получить информацию о том, что сертификат был отозван, пока Microsoft выпустит, а пользователь не установит соответствующее исправление. Для обеспечения анонимности разработаны специальные криптографические протоколы. Они позволяют выполнять такие операции, как тайное компьютеризированное голосование и анонимные не отслеживаемые деньги для оплаты товаров и услуг через Интернет.
