• Риск № 1: Кому мы доверяем и почему
  • Риск № 2: Кто использует мой ключ
  • Риск № 3: Как обеспечивается безопасность контролирующего компьютера
  • Риск № 4: Который из Джонов Робинсонов
  • Риск № 5: Какие полномочия имеет Центр сертификации
  • Риск № 6: Является ли пользователь частью системы безопасности
  • Риск № 7: Что лучше: Центр сертификации или Центр сертификации плюс Центр регистрации
  • Риск № 8: Как Центр сертификации отождествляет держателя сертификата
  • Риск № 9: Как обеспечивается безопасность сертификатов на практике
  • Риск № 10: Так почему же мы все равно используем Центры сертификации

  • Скачать 84.36 Kb.


    Дата21.03.2019
    Размер84.36 Kb.
    ТипСтатья

    Скачать 84.36 Kb.

    Десять рисков pki: чего не говорят об инфраструктуре открытых ключей



    ДЕСЯТЬ РИСКОВ PKI: ЧЕГО НЕ ГОВОРЯТ ОБ ИНФРАСТРУКТУРЕ ОТКРЫТЫХ КЛЮЧЕЙ*

    Карл Еллисон,

    Брюс Шнеер

    *Статья публикуется с сокращениями.

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

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

    Появившись на свет несколько лет тому назад, технология PKI вызвала много шума в прессе: даже 1999 год был назван «годом инфраструктуры открытых ключей». Высокие темпы инвестиций в эту технологию прогнозируют специалисты компании Datamonitor. В своем отчете «Creating Trust: PKI and authentication and encryption technologies» они утверждают, что программные системы на основе PKI в ближайшем будущем станут основным выбором электронного бизнес-сообщества для идентификации и шифрования. В отчете говорится о том, что темпы роста популярности PKI еще больше увеличатся с развитием беспроводных коммуникаций, а операторы беспроводной связи станут одним из важнейших сегментов пользователей этой технологии, а также основным каналом распространения цифровых сертификатов.

    Аналитики Datamonitor предполагают, что общемировой объем инвестиций в PKI-продукты увеличится с 436 млн долл. в 2000 году до 3,4 млрд долл. в 2006 году. В 2001 году доходы от предоставления услуг идентификации по сертификатам составили более 350 млн долл., тогда как в 2006 году они составят 1,4 млрд долл. Согласно Datamonitor, существенно увеличатся объемы доходов от использования PKI и на мобильных устройствах.

    Другая компания, IDC, также пророчит высокие темпы роста рынка решений PKI: до 60 % в год. Сегодня операционная система Windows-2000 уже имеет встроенную PKI-систему. А цены на PKI падают: аналитики предсказывают их снижение на 30–40 % в ближайшие несколько лет.

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

    Но, несмотря на это, популярность PKI продолжает расти.

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

    Однако данной технологии присущи и определенные риски, которые подстерегают каждого, кто решит использовать коммерческие PKI-продукты.

    Риск № 1:

    Кому мы доверяем и почему?

    В этом случае риск исходит от использования слова «доверие». Очень часто Центр сертификации определяют как «надежный». Однако возникает вопрос, кто дал Центру сертификации полномочия на выдачу сертификатов и что делает его надежным? Можем ли мы доверять сертификату, выданному Центром сертификации?

    Для успешной реализации Центра сертификации, в зависимости от уровня необходимой авторизации, оператор Центра должен либо написать специальное положение об использовании сертификата, либо составить общее CPS. Но как реализуется CPS на практике и какая предусмотрена защита сертификата в приложениях? Какие полномочия предоставляют центры сертификации на использование ID-сертификатов? Любой человек может присвоить то или иное имя. Мы делаем это все время.

    Те, кто пытаются убедить клиента установить PKI, говорят: (1) у вас есть ID-сертификат, (2) это дает вам имя владельца ключа, (3) вы знаете, кто владелец ключа, (4) это все, что вам необходимо знать. Однако это не то, что вам необходимо знать. К тому же логические связи между 1-м и 2-м утверждениями, 2-м и 3-м, а также 3-м и 4-м имеют изъяны.



    Риск № 2:

    Кто использует мой ключ?

    Одним из основных рисков является безопасность ключа. Как вы его храните?

    Обычно люди хранят ключи на компьютере. Но защищен ли компьютер от несанкционированного доступа, от утечки информации через ПЭМИН и другие каналы. Защищено ли помещение, в котором стоит компьютер, установлена ли система видеонаблюдения? Что, если ключ попадет в руки злоумышленника?

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



    Риск № 3:

    Как обеспечивается безопасность контролирующего компьютера?

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

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

    Риск № 4:

    Который из Джонов Робинсонов?

    Сертификаты обычно ассоциируют открытый ключ с именем человека, но эта ассоциация малопригодна на практике. Представьте, что вы получаете сертификат от Джона Робинсона. Вероятно, вы знаете Джона Робинсона лично. Но сколько людей с таким именем зарегистрировано в Центре сертификации? Тот ли это Джон Робинсон, от которого вы ждете сертификат?

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

    Риск № 5:

    Какие полномочия имеет Центр сертификации?

    У Центра сертификации есть полномочия на изготовление сертификатов, но распространяются ли его полномочия на то, что содержат сертификаты. Например, сертификат SSL-сервера содержит две составляющие данных, которые представляют потенциальный интерес в смысле обеспечения безопасности: имя держателя ключа (обычно это корпоративное имя) и DNS-имя для сервера. Когда некоторый сервер захватывает сертификат SSL-сервера, он получает разрешение на установление SSLсоединения. Кто предоставил полномочия Центру сертификации управлять таким разрешением? Так ли это необходимо? Обеспечивает ли это безопасность соединения? Вероятно, нет.



    Риск № 6:

    Является ли пользователь частью системы безопасности?

    Другими словами, берет ли в расчет приложение, использующее сертификаты, пользователя или заботится только о себе, используя средства криптографии?

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

    Риск № 7:

    Что лучше: Центр сертификации или Центр сертификации плюс Центр регистрации?

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

    Тем не менее модель ЦР+ЦС менее защищена, чем модель системы только с ЦС, наделенным полномочиями ЦР, поскольку необходимо, кроме всего прочего, обеспечивать безопасность связи ЦР+ЦС. Конечно, модель с ЦС, наделенным полномочиями ЦР, нарушает некоторые принципы построения PKI, но она более безопасна.

    Риск № 8:

    Как Центр сертификации отождествляет держателя сертификата?

    Центр сертификации, перед тем как выпустить сертификат, должен идентифицировать кандидата на этот сертификат.

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

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



    Риск № 9:

    Как обеспечивается безопасность сертификатов на практике?

    Сертификаты не являются неким магическим средством безопасности: для обеспечения таковой сертификаты следует использовать должным образом.

    Высокая степень безопасности должна быть заложена при изначальном проектировании системы, она должна учитывать вероятное поведение злоумышленников. Только имитация поведения хакера может выявить уязвимые точки системы. Однако возможно ли спрогнозировать все угрозы и прочие условия безопасного функционирования системы?

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

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

    Как владелец сертификата отказывается от ранее сделанной подписи? Каким образом датируются подписи и как распознать «хорошая» ли эта подпись? Какова длина открытых ключей и почему она была выбрана именно такой?

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

    Риск № 10:

    Так почему же мы все равно используем Центры сертификации?

    Один из продавцов PKI рассказывал, что, когда несколько лет назад они установили систему у некоего клиента, тот остался недоволен. После установки Центра сертификации и издания сертификатов для всех служащих он спросил: «Хорошо, а как сделать однократную регистрацию в системе?» и получил ответ: «Это невозможно, так как потребует внесения изменений в систему».

    Между тем однократная регистрация (Singl Sign-On, SSO) очень привлекательна для пользователя. Каждое утро многие из нас начинают с того, что садятся за компьютер и набирают пароль, для того чтобы сетевая операционная система могла нас идентифицировать. В течение дня нам может потребоваться ввести дополнительные пароли: один для сервера электронной почты, другой – для сервера базы данных и т.д. Если пользователю приходится применять пять-шесть паролей, то время от времени он забывает какой-либо из них и начинает сильно нервничать, что в конце концов сказывается на администраторе сети. Однако однократная регистрация не только сохраняет нервы пользователю, но и позволяет точно опознать человека, работающего в данный момент на компьютере.

    Так почему же многие устанавливают PKI и используют несовершенные решения? Только потому, что их сосед (конкурент, друг) сделал то же самое? Конечно же нет. Никто не намерен отрицать возможность внедрения PKI и преимущества данной технологии. Просто следует всегда помнить, что обеспечение безопасности – задача не из легких и относиться к ней следует со всей серьезностью и ответственностью.



    «Защита информации. Конфидент», №6, 2002, с. 39-41

    Коьрта
    Контакты

        Главная страница


    Десять рисков pki: чего не говорят об инфраструктуре открытых ключей

    Скачать 84.36 Kb.