Идентификация и криптография

Шифрование с открытыми/личными ключами и цифровые сертификаты позволяют обеспечить идентификацию и контроль доступа во всей сети - но не все так гладко.

ДОСТАТОЧНО ХОРОШАЯ ИДЕНТИФИКАЦИЯ?
Общие секреты

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

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

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

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

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

ИДЕНТИФИКАЦИЯ ПО ПРОВОДУ

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

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

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

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

Более надежной идентификации можно достичь за счет комбинации этих методов: у вас есть банковская карточка и вы знаете PIN.

Базовая реализация идентификации на основе паролей имеет довольно много потенциальных дыр, когда пароли передаются по линии открытым текстом. Если бы создатели ранних версий UNIX позаботились об усовершенствовании этой модели, то спрос на защиту с помощью брандмауэров был бы не столь высок. Однако разработчики UNIX обладают каким-то геном авантюризма, причем проявляется он главным образом в отношении защиты: корпоративная служба каталогов Sun Directory Services, представленная Sun Microsystems в сентябре 1997 года, передает пароли от пользователя к серверу и между серверами открытым текстом!

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

ДВА ПОДХОДА К ШИФРОВАНИЮ

При передаче по незащищенным каналам пароли желательно по крайней мере шифровать. Методы шифрования можно разделить на два наиболее общих типа: с секретным ключом и с открытым ключом. Шифрование с секретным ключом симметрично - ключ, с помощью которого текст шифруется, применяется и для его дешифровки. Наверное, наиболее известной системой с секретными ключами является стандарт шифрования данных (Data Encryption Standard, DES), находящийся в настоящее время в ведении Национального агентства безопасности и Национального института стандартов и технологий. Альтернативную систему представляет международный алгоритм шифрования данных (International Data Encryption Algo-rithm, IDEA), обеспечивающий более надежное шифрование, чем DES и даже тройной DES (гораздо более надежная разновидность DES). Кроме того, его использование предполагает применение меньших вычислительных мощностей. IDEA реализована в системе Pretty Good Privacy (PGP).

Шифрование с открытыми ключами осуществляется с помощью двух ключей, поэтому оно относится к асимметричным системам шифрования. Открытый ключ не является секретным; более того, его доступность для всех и каждого, например за счет публикации в каталоге или включения в незащищенное сообщение электронной почты, имеет принципиальное значение для функционирования всей системы. Другой ключ, личный, служит для шифрования текстов, дешифруемых с помощью открытого ключа, или, чаще, для дешифрования полученных текстов, зашифрованных с помощью открытого ключа (см. Таблицу 1). (Дополнительную информацию по этому вопросу можно найти в статье Аниты Карве "Инфраструктура с открытыми ключами" в декабрьском номере журнала LAN за прошлый год.)

ТАБЛИЦА 1 - ЗАДАЧИ КРИПТОГРАФИИ С ОТКРЫТЫМИ КЛЮЧАМИ

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

В смысле сервисов идентификации шифрование с секретными ключами эквивалентно системам с открытыми ключами, однако главной проблемой здесь является распространение ключей. Как передать ключи в руки пользователей или в память процесса (это могут быть люди, компьютеры или программные модули, здесь всех их мы объединим под понятием "принципал") так, чтобы при этом никто их не подглядел? Вероятно, наиболее широко распространенной системой с секретными ключами является Kerberos, использование которой предполагает наличие высоконадежного сервера, хранящего исходные копии ключей для взаимодействия с каждым принципалом. Желающие аутентифицировать или зашифровать сеанс с другим принципалом получают ключи для этих целей защищенным образом. Kerberos представляет собой часть спецификации открытой вычислительной среды (Distributed Computing Environ-ment, DCE) фонда OSF. Среди предлагающих продукты на базе DCE такие компании, как IBM и Hewlett-Packard. Kerberos должен стать также частью системы защиты Windows NT 5.0. Тем не менее сегодня системы на базе Kerberos не пользуются особой популярностью. Основные надежды, ресурсы и усилия в области криптографических систем сосредоточены на системах с открытыми ключами.

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

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

Стандарт X.509, точнее, его последняя третья версия, определяет компоненты цифрового сертификата. Основными его компонентами являются имя субъекта или принципала, информация об открытом ключе субъекта и цифровая подпись уполномоченного по выдаче сертификатов. (Цифровая подпись гарантирует, что сертификат не был изменен и что его обладатель от него не откажется; эти факты могут быть проверены с помощью открытого ключа уполномоченного.) Цифровой сертификат X.509 v3 содержит также имя выпустившего его, уникальный идентификатор выпустившего, уникальный идентификатор субъекта, порядковый номер сертификата, срок годности (сертификаты выдаются на ограниченный срок), информацию о версии сертификата и алгоритме подписи, а также, возможно, некоторые нестандартные параметры. Пользователи Novell Directory Services, Lotus Notes и PGP используют цифровые сертификаты, хотя и несовместимые со стандартом X.509. Lotus и Novell объя-вили о своих намерениях привести сертификаты в соответствие со стандартом в следующих версиях своих продуктов.

ИЗЪЯНЫ ИНФРАСТРУКТУРЫ С ОТКРЫТЫМИ КЛЮЧАМИ

Уполномоченный по выдаче сертификатов представляется многим непонятным и загадочным посредником. Загляните в разделы конфигурации или защиты содержимого в любом своем браузере и посмотрите, если там кто-либо в списке, кому бы вы доверяли как авторитету в деле идентификации открытых ключей. Если вы работаете в GTE или Sprint, то насколько вы согласны доверять AT&T или MCI как своему уполномоченному? Имеет ли новоявленная компания достаточно финансовых ресурсов на покрытие претензий, если что-то окажется не так? Захотят ли люди платить за сертификацию столько, сколько хватило бы для выживания коммерческих уполномоченных? А быть может, эта роль должна быть отведена правительству?

Задача уполномоченного не ограничивается выпуском цифровых сертификатов. Он должен также создать и поддерживать списки аннулированных сертификатов (Certificate Revocation List, CRL). Если ваш личный ключ был утерян или украден, если вы сбежали к конкуренту своего работодателя или перешли на новую работу, при которой доступ к данным не нужен, то действительный цифровой сертификат необходимо аннулировать каким-то образом. Итак, процесс ратификации цифрового сертификата включает проверку того, что открытый ключ уполномоченного действителен, что сертификат не был изменен, и что сертификат не был аннулирован. Многие специалисты по информационной защите выражают озабоченность относительно масштабируемости списков CRL. Если срок действия сертификата достаточно велик, то списки CRL будут неизбежно расти и потребуют дополнительных компьютерных ресурсов для осуществления поиска. С другой стороны, слишком частый выпуск сертификатов может тоже обернуться дополнительной административной нагрузкой. Если сертификаты используются для коммерческих транзакций - иначе, кто станет заниматься созданием такой сложной инфраструктуры, - записи о сертификатах и списки CRL должны храниться в архиве продолжительное время.

Другая проблема с уполномоченными состоит в том, как они будут взаимодействовать друг с другом. Разумным решением представляется сертификация компаниeй А, выполняющей роль уполномоченного, компании Б, также выступающей в качестве уполномоченного. Но всегда ли вы согласитесь доверять уполномоченному неизвестного лица, желающего вести с вами бизнес по Internet? И всегда ли транзитивные отношения между уполномоченными заслуживают доверия: если уполномоченный Б доверяет уполномоченному В, а ваш уполномоченный А доверяет Б, то должны ли вы автоматически доверять В? И каким образом при положительном решении установить, что неразрывная цепочка доверительных отношений существует между вашим доверенным и неизвестным уполномоченным? И если такую цепочку проследить все-таки возможно, то будет ли она масштабироваться адекватным образом или затраты на вычисления и длительная задержка сведут на нет все ваши усилия? Стандарт X.509 предусматривает так называемые обратные сертификаты, содержащие сертифицированные ключи других уполномоченных. Это делает возможным взаимную сертификацию, но не решает архитектурных вопросов идентификации и вычисления цепочки доверительных отношений.

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

УПРАВЛЕНИЕ СЕРТИФИКАТАМИ И КЛЮЧАМИ

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

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

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

Кроме того, ключи полезно периодически обновлять. Как и создание исходной пары ключей, модификация ключей может оказаться дорогостоящей с точки зрения количества циклов ЦПУ. Неплохая идея - разнести сроки обновления во времени. Разумеется, после выпуска новых открытых ключей они должны быть также удостоверены сертификатом. Автоматизировать эти операции позволяет ряд систем защиты, например Entrust/Manager.

ДОСТИЖЕНИЕ ИНТЕРОПЕРАБЕЛЬНОСТИ

Идентификация необходима для контроля доступа. Для реализации идентификации и контроля доступа в масштабах предприятия наилучшим решением является развертывание универсальной службы каталогов или метакаталога для унифицированного просмотра разнородных каталогов. Каталог представляется естественным местом для помещения открытых ключей и сертификатов для всеобщего доступа, а надежно защищенный каталог - для хранения личных ключей. К сожалению, лишь немногие организации имеют универсальный каталог или метакаталог, не говоря уже о возможности запросов к существующим каталогам с помощью LDAP. В большинстве случаев идея создания нового каталога для хранения ключей и сертификатов представляется неразумной. Решение, при котором клиентские системы хранят свои собственные ключи, плохо масштабируется и представляет собой настоящий кошмар с точки зрения управления. Так что одна из задач в области достижения интероперабельности состоит в разработке инфраструктуры каталогов для хранения и контроля компонентов инфраструктуры с открытыми ключами.

Но если ситуация с интероперабельностью каталога просто плоха, то положение с интероперабельностью инфраструктур с открытыми ключами иначе как ужасным не назовешь. В своих продуктах Novell и Lotus используют нестандартные форматы цифровых сертификатов. Браузеры Netscape и Microsoft могут использовать сертификаты X.509 для идентификации сервера Web, но эта защита на транспортном уровне (известная как SSL) тесно привязана именно к браузерам. Ряд продуктов существует для аутентификации и шифрования электронной почты. Так, серия продуктов, реализующая Secure/MIME, успешно прошла тесты на взаимодействие друг с другом.

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

Хорошо, однако, то, что достигнуто согласие относительно состава сертификатов X.509, а крупнейшие разработчики нестандартных цифровых сертификатов намереваются реализовать стандартные. Кроме того, стандарты на криптографию с открытыми ключами от RSA обеспечивают реальный набор криптографических алгоритмов для всех сколько-нибудь значимых платформ. Эти стандарты обеспечивают базис для будущей интероперабельности операций идентификации и других криптографических операций.

ДОСТАТОЧНО ХОРОШАЯ ИДЕНТИФИКАЦИЯ?

Общие секреты

В физическом мире мы вынуждены иногда идентифицировать себя на основании того, что знаем. Такими общими секретами могут быть девичья фамилия матери или номер школы. Недавно разразился скандал по поводу того, что управление социального обеспечения США разрешило людям обращаться к своим записям о месте работы по Internet, для чего они должны были указать свою дату рождения, номер страхового свидетельства и девичью фамилию матери. Это вызвало поток упреков в неспособности министерства обеспечить конфиденциальность информации. Однако оказалось, что справку о местe работы можно было всегда получить по представлению бумажной формы с указанием номера страховки и девичьей фамилии матери. Иногда поборники конфиденциальности применяют двойной стандарт в отношении электронных и бумажных записей.