Профили защиты, разработанные на основе "Общих критериев". Часть 3. Частные требования к комбинациям и приложениям сервисов безопасности

Смарт-карты

Профиль защиты для смарт-карт [ 80 ] интересен необычностью объекта оценки. Он позволяет оценить гибкость и разнообразие требований "Общих критериев".

Эта необычность заключается в следующем:

• минимум аппаратных ресурсов (интегральная схема, включающая процессор; оперативная и постоянная память относительно небольшого объема; порты ввода/вывода) в сочетании с программным обеспечением ограниченной функциональности (в профиле [ 80 ] рассматривается базовое ПО);
• принадлежность неконтролируемой среде, когда карта может оказаться в руках злоумышленника, располагающего специальным оборудованием.

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

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

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

Сформулируем предположения безопасности для среды:

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

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

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

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

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

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

Перейдем к рассмотрению специфических функциональных требований:

• автоматическая реакция аудита безопасности (FAU_ARP) при обнаружении возможного нарушения безопасности. Предписываются минимальные необратимые последствия реакции. Подчеркнем, что в силу специфики объекта оценки оперативное информирование администратора безопасности в общем случае невозможно; с опасностью приходится бороться самостоятельно;
• генерация списка регистрационных данных (FAU_LST - дополнительное семейство). На интегральной схеме, устанавливаемой в смарт-карте, нет часов; время указывает только приемное устройство, которое не считается доверенным. Следовательно, события можно лишь упорядочить по мере их появления, но с ними нельзя ассоциировать дату и время. В регистрационную информацию должны включаться идентификационные данные аппаратных и программных компонентов;
• противодействие физическому нападению (FPT_PHP.3). Функции безопасности обязаны противодействовать попыткам эксплуатации в стрессовых условиях, отслеживанию информации, другим физическим атакам, автоматически реагируя таким образом, чтобы предотвратить нарушение политики безопасности (FPT_PHP.3.1);
• надежное восстановление (FPT_RCV). Автоматическое восстановление без недопустимой потери (FPT_RCV.3), восстановление функции (FPT_RCV.4).

Для требований доверия безопасности в [ 80 ] используется усиленный оценочный уровень 4. Усиление обеспечивают компоненты AVA_VLA.3 (систематический поиск уязвимостей, обеспечение стойкости к нападениям, выполняемым нарушителем с умеренным потенциалом) и ADV_INT.1 ( модульность ).

Важным достоинством работы [ 80 ] является выделение двух функциональных пакетов: для интегральной схемы и базового ПО. Эти части могут разрабатываться независимыми производителями, поэтому целесообразно, чтобы они проводили такую же независимую сертификацию, а интегратор (производитель смарт-карт ) выбирал поставщиков и осуществлял интегральную сертификацию. В части функциональных требований пакет для базового ПО аналогичен рассмотренному профилю ; к аппаратуре предъявляется меньшее число требований. Например, в функциональном пакете для интегральной схемы отсутствуют компоненты FAU_SAA.1 (анализ потенциального нарушения) и FPT_RPL.1 (обнаружение повторного использования), что представляется вполне естественным.