<< Предыдущая

стр. 5
(из 39 стр.)

ОГЛАВЛЕНИЕ

Следующая >>

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

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

Хэши паролей для LANMAN-аутентификации
В таких операционных системах, как Windows NT/2000, могут храниться две
версии хэшей пароля. Одна версия используется собственными средствами
безопасности Windows NT, а другая нужна для обеспечения совместимости с про-
токолом аутентификации LANMAN, применяемым, в частности, в Windows 95/98.
Глава 2. Основные способы обеспечения защиты 23

Собственный хэш Windows NT достаточно стойкий, и по значению хэша практи-
чески невозможно найти пароль, использующий цифры, буквы в разных регист-
рах и знаки препинания и имеющий длину более 8 символов. Однако процеду-
ра вычисления хэша LANMAN имеет несколько особенностей, которые
значительно ослабляют уровень защиты.

При вычислении хэша LANMAN-пароль, длина которого не должна превышать
14 символов, разбивается на 2 части по 7 символов, и хэш для каждой части
вычисляется отдельно. Таким образом, при подборе пароля максимальная
длина проверяемых слов составляет всего 7 символов, что делает возможным
даже полный перебор всех вариантов пароля.

Если пароль не длиннее 7 символов, то вторая часть остается пустой и порож-
дает всегда одно и то же значение хэша. Это позволяет по второй половине
хэша сразу определить пароли, которые короче 8 символов.

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

Перед вычислением хэша все буквы пароля переводятся в заглавные, что при-
мерно в 9,4 раза сокращает количество возможных комбинаций (при использо-
вании всех символов ASCII).

Функция вычисления хэша LANMAN не использует подмешивание "соли"
(salt) — случайной несекретной величины, делающей значение хэша уникаль-
ным для каждого пользователя, даже если пароли совпадают. Эта особенность
позволяет тратить на подбор пароля для любого числа пользователей практи-
чески одинаковое время, т. к. на каждого дополнительного пользователя до-
бавляется лишь одна операция сравнения, которая выполняется в тысячи раз
быстрее, чем вычисление хэша.

После того как по хэшу LANMAN подобран пароль, можно за короткое время
подобрать и пароль NT, если его длина не превышает 14 символов. На это по-
требуется не более 2 м вариаций прописных и строчных букв, т. е. не более
16 384 комбинаций.


• Минимизировать вероятность ошибок первого рода (отказ в доступе ле-
гитимному пользователю) и второго рода (предоставление доступа поль-
зователю, не имеющему на это права). При использовании биометрики
для идентификации и/или аутентификации ошибки первого и второго
рода играют значительную роль, т. к. биометрика при оценке степени
совпадения измеренной биофизической характеристики и ранее сохра-
24_ Часть I. Кому нужна защита?

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


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

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

Биометрика может применяться либо для идентификации совмещенной с аутен-
тификацией, либо только для аутентификации. При первом подходе снятая
биометрическими методами характеристика сравнивается с учетными запися-
ми всех пользователей, зарегистрированных в системе, и если точность совпа-
дения превышает установленное значение, пользователь считается идентифи-
цированным и аутентифицированным. Второй подход требует предоставления
идентификатора (имени пользователя, пластиковой карты), а биометрические
методы лишь подтверждают его аутентичность. Этот способ хоть и является
менее удобным для пользователей, имеет несколько преимуществ. Во-первых,
требуется сравнить снятую характеристику только с одним сохраненным значе-
нием, а не со всеми. Это может оказаться очень существенным, когда число
зарегистрированных пользователей измеряется тысячами. А во-вторых, при
наличии традиционного идентификатора гораздо проще пресекать многократ-
ные попытки входа в систему нелегального пользователя — достаточно ввести
ограничение на максимальное количество попыток входа одного пользователя
Глава 2. Основные способы обеспечения защиты 25

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


При решении таких задач информационной безопасности, как уполномочи-
вание, контроль доступа и обеспечение права собственности, не требуется
что-либо защищать. Права доступа к различным объектам определяются
формальными правилами в соответствии с используемой моделью управле-
ния доступом.
Существует две основных модели разграничения доступа: мандатная и дис-
креционная.
Мандатное разграничение доступа заключается в том, что компьютерные
ресурсы разделяются на группы в соответствии с уровнями их конфиденци-
альности. Каждому ресурсу присваивается классификационная метка, за-
дающая назначенный ему уровень. Полномочия пользователя задаются мак-
симальным уровнем конфиденциальности информации, доступ к которой
ему разрешен. В соответствии с этим разрешается доступ только к данным,
уровень секретности которых не выше уровня полномочий пользователя.
Дискреционное управление доступом — это метод ограничения доступа
к компьютерным ресурсам, основанный на учете прав пользователя или
группы, в которую этот пользователь входит. Использование данной модели
позволяет для каждого пользователя или для каждой группы пользователей
явно задать полномочия, указав список ресурсов (логические диски, эле-
менты файловой структуры, порты ввода-вывода и т. д.), к которым разре-
шен доступ, а также права доступа к этим ресурсам. Один из видов полно-
мочий дает пользователю возможность передать права доступа любому
другому пользователю или группе.
Существуют и иные виды разграничения доступа, не попадающие ни под
мандатную, ни под дискреционную модель. Но подробное рассмотрение
систем разграничения доступа выходит за рамки книги.
Задачи сертификации в настоящее время встречаются повсеместно, и для
решения этих задач используется криптография с открытым ключом. При
выдаче сертификата удостоверяющая сторона гарантирует, что содержимое
сертификата является подлинным и может быть использовано при выпол-
нении условия правильности сертификата. Чаще всего сертификаты выда-
ются на открытые ключи и исполняемые файлы.
При использовании криптографии с открытым ключом большой проблемой
является доверие к подлинности открытого ключа адресата. Сам открытый
26 Часть I. Кому нужна защита?

ключ может быть создан любым человеком, и если он получен не из сто-
процентно безопасного источника (например лично из рук адресата), нельзя
быть полностью уверенным в том, что это не подделка, выполненная про-
тивником. Использование сертификатов открытых ключей позволяет ре-
шить эту проблему. Достаточно иметь один или несколько так называемых
корневых сертификатов — сертификатов открытых ключей, принадлежащих
базовым удостоверяющим-центрам и подлинность которых может быть про-
верена множеством способов. Корневой сертификат может быть использо-
ван для удостоверения подлинности другого открытого ключа, доверие
к которому будет основываться на доверии к базовому удостоверяющему
центру, а не к источнику получения ключа. Сертификация также может
быть выполнена цепочкой удостоверяющих центров, что не снижает дове-
рия к сертифицируемому открытому ключу, если, конечно, ни один из цен-
тров сертификации, участвовавших в цепочке, не был скомпрометирован.
Сертификация исполняемых файлов позволяет подтвердить, что файл был
создан именно разработчиком, которому принадлежит сертифицирующий
ключ. Это является своеобразной гарантией безопасности: если при исполь-
зовании сертифицированного исполняемого файла возникают проблемы,
всегда можно найти, к кому обращаться с вопросами. А в некоторых случаях
разрешено использование исключительно сертифицированных модулей.
Так, например, любой криптопровайдер (Cryptographic Service Provider,
CSP — модуль, отвечающий за поддержку криптографических функций че-
рез стандартный программный интерфейс), используемый в современных
версиях Windows, должен быть предварительно сертифицирован компанией
Microsoft.

RSA в библиотеке ADVAPI32.DLL
КЛЮЧИ
В январе 2003 года в конференции fido7.ru.crypt появилось сообщение, ка-
сающееся процедуры подписания криптопровайдеров в Windows. В сообщении
утверждалось, что отсутствие желания каждый раз обращаться в Microsoft
и тратить несколько дней на подписание разрабатываемого модуля подтолкну-
ло к поиску более эффективного решения. Это решение заключалось в факто-
ризации (разложении на простые сомножители) модуля 512-битового ключа
RSA, используемого при проверке подписи и хранящегося в библиотеке
ADVAPI32.DLL. По утверждению автора сообщения для факторизации потре-
бовалось чуть больше двух месяцев. Вычисления выполнялись на кластере из
10 машин с процессорами Pentium-Ill, работающими на частотах от 500 до
1200 МГц. Однако строгих доказательств выполненной факторизации, похоже,
опубликовано не было.

На самом деле, в библиотеке ADVAPI32.DLL операционных систем семейства
NT (Windows NT, 2000 и ХР) находится не один, а целых три RSA-ключа, замас-
Глава 2. Основные способы обеспечения защиты 27

кированных одинаковым образом. Два из них имеют длину 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 уже вышел, и он продолжает загружать модули расшире-
ния, подписанные разработчиками старым уязвимым способом.

Решение таких задач, как неотказуемость, расписка в получении, свидетель-
ствование и датирование, тесно связано с решением задач сертификации и
28 Часть /. Кому нужна защита?

подписи и тоже обеспечивается методами асимметричной криптографии.
Аннулирование заключается в обновлении списков отозванных сертифика-
тов (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 выпустит, а пользователь не
установит соответствующее исправление.


Для обеспечения анонимности разработаны специальные криптографиче-
ские протоколы. Они позволяют выполнять такие операции, как тайное
компьютеризированное голосование и анонимные не отслеживаемые деньги
для оплаты товаров и услуг через Интернет.
Глава 3


<< Предыдущая

стр. 5
(из 39 стр.)

ОГЛАВЛЕНИЕ

Следующая >>