Сертификаты

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

Существуют стандарты на сертификаты, принятые Международным Союзом Телекоммуникаций  ITU. В настоящее время действующий стандарт  X.509. Наиболее распространенные варианты сертификатов  X.509v1 и X.509v3.

Конечно же, не составляет технических проблем поместить сертификат во внешнее аппаратной устройство. Подавляющее большинство современных устройств доступа  это фактически сертификат, помещенный внутрь микросхемы. Примеры таких устройств  E-Tokens, смарт-карты и т.п.

На каждом органе сертификации существует специальный список отозванных (недействительных) сертификатов  Certificate Revocation List. На нем тот, кто пользуется сертификатами этого CA, может проверить действительность того или иного сертификата.

Контрольные вопросы

1. Что такое хеширование?

2. Чем архитектура электронной цифровой подписи отличается от архитектуры шифрования с открытым ключом?

3. Что такое сертификат?

4. В чем преимущества симметричного шифрования перед асимметричным?

5. В чем разница между открытым и закрытым ключом в алгоритмах асимметричного шифрования?

Лекция 13. Определение безопасности информационных систем. Экспериментальный подход

Экспериментальный подход заключается в проведении атаки и проверки, осуществилась ли атака или нет.

Основные понятия: атака, эксплойт, уязвимость. Классификация уязвимостей.

Атака – реализация угрозы безопасности. Атаки не описаны ни в моделях безопасности, ни в стандартах. Невозможно перечислить все способы и реализации атак.

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

Защита реальных систем не может быть безупречной. Чтобы найти уязвимость, необязательно знать детали реализации атакуемой системы.

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

Безопасность (на практике) – успешное противостояние атакам. Тогда система безопасна, если не содержит уязвимостей.

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

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

Типичная уязвимость – уязвимость, использующая переполнение буфера.

Способы борьбы с переполнением буфера:

1. Запрет выполнения стека (Intel)

2. Сохранение в стеке случайного количества параметров. Но при этом нельзя узнать, где точка возврата.

3. Установка границ буфера с помощью некоторого случайного числа.

Уязвимости появляются вследствие ошибок проектирования, реализации и конфигурирования. При этом не все ошибки могут приводить к уязвимостям.

Уязвимости могут быть классифицированы, например, следующим образом:

1. по этапам разработки и эксплуатации:

• уязвимости этапа проектирования;

• уязвимости этапа реализации;

• уязвимости этапа конфигурирования.

2. по расположению: в стеке, в куче и др.

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

Модель противостояния угроз и средств защиты.

Уязвимость возникает по двум причинам:

1. Существуют ошибки в средствах защиты.

2. Незнание об угрозе или предположение о том, что данной угрозы не будет в системе. Нарушитель может использовать угрозы, которые, при проектировании средств защиты не учитывались. То есть нарушитель должен найти ошибки в обоснованиях угроз, от которых защищают средства защиты.

Рис. 13.1 Противостояние угроз и средств защиты

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

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

Оценивать безопасность можно по количеству уязвимостей.

Борьба с ошибками в средствах защиты:

1. Уменьшение объема кода средств защиты.

2. Усиление тестирования.

3. Сертификация.

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

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

Оценка безопасности системы:

1. Проверка известных уязвимостей;

2. Поиск новых уязвимостей.

Обеспечение безопасности системы:

1. Контроль и своевременное исправление ошибок.

2. Минимизация объема кода средств защиты.

3. Контроль за тем, чтобы не было программного обеспечения, которое не контролировалось бы средствами защиты;

4. Уменьшение привилегий программ.

Предусловия – логический предикат, который истинен до выполнения процедуры. Постусловия – логический предикат, который истинен после выполнения процедуры. Для доказательства корректности работы программ строятся формальные логические выводы на основе предусловий и постусловий.

Пример уязвимости: уязвимость в драйверах. Плюсы и минусы экспериментального подхода.

Практически драйвер может прочитать файл, который пользователь прочитать не может. При проектировании Windows эти угрозы считались несущественными, т.к. в компании Microsoft считали, что разрабатывать драйвера будут либо сотрудники , Microsoft либо производители устройств.

В драйвере может оказаться ошибка, которая позволит нарушителю заменить код драйвера, или выполнить произвольный.

Решение:

1. Запрет модификации компонентов. Это возможно только до некоторого уровня, т.к. драйвера необходимо устанавливать, или обновлять.

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

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

Корректность работы средств защиты зависит от выбранной доверенной среды. К уязвимостям в средствах защиты может привести любая ошибка. Данный подход представлен на рис. 13.2.

Рис. 13.2. Экспериментальный подход

Следовательно, во избежание ошибок необходимо:

1. минимизировать средства защиты;

2. перенести по максимуму функциональность из драйвера в приложение

В этом случае рис. 13.2 изменится следующим образом (рис. 13.3):

Рис. 13.3. Модификация экспериментального подхода

Достоинства и недостатки экспериментального подхода:

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

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

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