Как нужно защищать микропроцессорные карточки
От чего и как именно следует защищать микропроцессорные карточки? Эта тема периодически «всплывает» в печати, на конференциях, посвященных проблемам безопасности и защиты данных, становится предметом оживленных дискуссий «по результатам очередных взломов», объектом активных изысканий компаний- разработчиков и даже...превращается в один из инструментов конкурентной борьбы - между производителями карточек, разработчиками операционных систем, самими международными платежными системами (но об этом - чуть позже).
До недавнего времени безопасность карточек оценивалась всеми по-разному. Наиболее «продвинутые» разработчики операционных систем апеллировали к «Оранжевой Книге». Производители микрокристаллов для карточек в сопроводительной документации к своим продуктам указывали, что чипы защищены от извлечения информации посредством спиливания, ультрафиолетового излучения, температурных воздействий и т. д.). В какой степени и какими методами эта защита реализовывалась, потребители продукции обычно не информировались. Поэтому сравнение между собой двух кристаллов от различных производителей по степени защищенности было весьма неблагодарным занятием - даже после появления ITSEC (который, кстати говоря, признавался и использовался далеко не во всех странах, где получили хождение микропроцессорные карточки). Лишь в 1999 г. появились «правила игры» для всех - «Общие Критерии», которые легли в основу международного стандарта ISO FDIS15408 «Критерии оценки безопасности информационных технологий».
Немного истории
В начале 80-х Федеральное агентство NCA (США) разработало так называемые Критерии оценки компьютерных систем (документ, более известный как «Оранжевая Книга» или TSEC). Чуть позже к созданию собственных спецификаций приступили и европейские страны, однако следует отметить, что и новые разработки в большинстве своем базировались на идеях, почерпнутых из «Оранжевой Книги».
Несколько позже, в мае 1990 г. четыре государства - Франция, Германия, Нидерланды и Великобритания - опубликовали совместные Критерии Оценки Информационной безопасности (Information Technology Security Evaluation Criteria - ITSEC) - структурированный набор требований к критериям и методам определения компьютерной безопасности систем и отдельных информационных продуктов. В настоящее время еще несколько европейских стран Европейского Союза, а также Австралия сообщили о своем признании методики ITSEC.
Безопасность по ITSEC оценивается с помощью нескольких уровней информационной безопасности - от E0 (низший уровень) до E6 (высший уровень). Тестирование по методике ITSEC прошли около 200 информационных продуктов. Максимальный уровень безопасности, когда-либо присваиваемый микропроцессорной карточке, - это ITSEC E4 [1]
В начале 1993 г. в Канаде были опубликованы Канадские Критерии общей оценки компьютерных продуктов - Canadian Trusted Computer Product Evaluation Criteria (CTCPEC), представляющие собой комбинацию ITSEC и TCSEC. В США авторы «Оранжевой Книги», федеральные агентства NIST and NSA, также решили не останавливаться на достигнутом. В 1993 г. был опубликован разработанный ими черновой вариант Федеральных Критериев оценки безопасности IT-систем (FC 1.0).
Таким образом, в мире появились как минимум три документа, регламентирующих правила определения уровня защищенности IT-продуктов (в число которых входят и микропроцессорные карточки). Совместимость и взаимная признаваемость этих документов, к сожалению, оставляла «желать лучшего». Эти обстоятельства (равно как и потребность в «общих правилах игры» в условиях обнародованных международными платежными ассоциациями планов перехода на микропроцессорные карточки), по-видимому, послужили своего рода катализатором процесса разработки единого стандарта оценки безопасности IT-продуктов.
В июне 1993 г. семь организаций, ответственных за выработку критериев безопасности в странах Европы и Северной Америки, объединили свои усилия и приступили к реализации проекта создания Общих Критериев. В этой работе активное участие приняла и международная организация по стандартизации ISO(а точнее, Объединенный технический комитет 1 - «Информационные Технологии»(JTC1), подкомитет 27 - Технологии обеспечения безопасности (SC27) и Рабочая Группа 3 - «Критерии безопасности» (WG3)), которая занималась созданием соответствующего стандарта начиная с 1990 г.
В 1994 г. на рассмотрение Рабочей Группы 3 был представлен черновой вариант будущего стандарта, первая версия которого была подготовлена в январе 1996 г. В апреле 1996 г. Международная организация стандартов представила ее на рассмотрение национальным организациям в качестве проекта будущего стандарта. Параллельно начались пилотные испытания, в результате которых проект подвергся переработке.
В апреле 1998 г. вышел новый вариант, который был направлен на рассмотрение ISO в качестве финального варианта. В декабре 1998 г. документ с незначительными поправками был одобрен в качестве проекта стандарта ISO 15408.
В мае 1999 г. вышла вторая версия Общих Критериев, а 8 июня 1999 г. центральный секретариат ISO и секретариат подкомитета SC27 сообщили, что все три части ISO FDIS15408 (СС) были поддержаны на Собрании национальных организаций, ответственных за внедрение стандартов ISO в своих странах. Таким образом, все, что осталось сделать, - это привести оформление документа в соответствие с правилами ISO и опубликовать его (текстовые изменения в тело документа вноситься уже не будут).
В целях исторической справедливости, ISO будет продолжать использовать термин «Общие Критерии» применительно к новому стандарту, хотя его официальное название - «Критерии оценки безопасности информационной технологии».
Общие Критерии
Стандарт «Общие Критерии оценки безопасности информационных технологий» (ISO15408, или Common Criteria) - создавался специально для оценки безопасности продуктов и систем информационной технологии, а также обеспечения сопоставимости результатов при оценке безопасности продуктов и систем уполномоченными третьими сторонами. «Общие Критерии» состоят из 3 частей:
часть 1: Введение и Общая модель (Introduction and General Model);
часть 2: Функциональные требования к безопасности (Security Functional Requirements);
часть 3: Требования по гарантиям безопасности (Security Assurance Requirements).
Впервой частистандарта определены концепция, общие принципы и структурная модель оценки безопасности IT-систем, описаны конструкции для постановки задач информационной безопасности, отбора и формулирования требований к информационной безопасности, а также подготовки спецификаций безопасности высокого уровня для конкретных продуктов и систем. Эти конструкции носят названия Профилей Защиты (Protection Profiles), Целей Защиты (Security Targets) и Пакетов (packages).
Профили Защиты
Профиль Защиты (Protection Profile, далее - PP) предназначен для пользователей, разработчиков и других сторон, заинтересованных в определении общего набора требований к безопасности IT-продуктов. PP представляет собой набор понятных и четко структурированных требований, отобранных из каталогов частей 2 и 3 стандарта ISO15408, к безопасности информационно-технологических продуктов. Потребители таких продуктов должны использовать PP при выдаче рекомендаций непосредственным производителям (разработчикам) продуктов.
PP имеет следующую структуру:
· Введение
· Описание Предмета оценки (Target of Evaluation - TOE) и его основного назначения (не обязательно с позиций безопасности);
· Описание Окружения Предмета оценки (TOE security environment) - детальное описание среды функционирования оцениваемого объекта с точки зрения безопасности, включая:
· описание аспектов безопасности ожидаемого использования и ограничений по использованию предмета оценки и его окружающей среды;
· угрозы безопасности, против которых либо в самом продукте, либо в его окружении должна быть предусмотрена специальная защита;
· организационную политику в области безопасности;
· Меры обеспечения безопасности (с учетом окружения TOE);
· Требования к IT-безопасности TOE;
· Замечания (дополнительная информация, которая может быть использована при создании, оценке или использовании продукта);
· Основания (разъяснения, как продукт, построенный в соответствии с PP, может быть эффективно использован, и почему для TOE предлагается тот или иной уровень защиты).
Цель Защиты
Цель Защиты (Security Target, далее ST) представляет собой перечень специальных требований к безопасности конкретного IT-продукта или системы, формулируемый в производителями (разработчиками) продукта. Кроме того, ST содержит спецификацию конкретных мер безопасности, позволяющих реализовать предъявляемые к продукту или системе требования.
Структура ST в основном дублирует структуру PP, хотя и включает некоторые дополнительные элементы, касающиеся специфических особенностей продукта. В принципе, ST может представлять собой набор ссылок на какой-либо PP или даже на соответствующие функциональные или иные компоненты Общих Критериев из каталогов частей 2 и 3 стандарта.
Кстати говоря, и PP, и ST также подлежат оценке на предмет соответствия требованиям к документам такого рода (полнота, последовательность, согласованность, технически грамотное изложение, пригодность для использования применительно к конкретному TOE). Эти требования, а также критерии оценки и методы проведения проверок содержатся в части 3 «Общих Критериев». Для оценки безопасности TOE следует использовать только проверенные PP и ST.
Во второй части Общих Критериев содержится структурированный список функциональных требований к безопасности, подразделяющийся на классы, семейства и компоненты.
Класс - это высокоуровневая группировка семейств требований к какой-либо общей функции. Во второй части стандарта определено 12 классов: «контроль безопасности», «коммуникации», «поддержка криптографии», «защита данных пользователя», «идентификация и аутентификация», «управление безопасностью», «сохранность тайны», «защита TOE», «утилизация ресурсов», «доступ к предмету оценки», «доверенные пути/каналы». Каждый из классов объединяет несколько семейств. Например, в класс «защита данных пользователя» входят такие семейства, как «политика контроля доступа», «функции контроля доступа», «аутентификация данных», политика контроля информационных потоков», «функции контроля информационных потоков», «целостность хранимых данных» и т. д.
Семейства - группировки более низкого уровня, объединяющие компоненты каких-либо специализированных задач безопасности. Каждое из семейств состоит из одного или нескольких компонентов. Например, в семейство «аутентификация данных» входят такие компоненты, как «базовая аутентификация» и «аутентификация с проверкой идентичности пользователя с использованием гарантий третьей стороны».
Компоненты представляют собой низкоуровневые структуры, которые могут включаться в PP, ST или package. При этом компоненты, в свою очередь, состоят из функциональных элементов.
Функциональный элемент - это минимальное функциональное требование к безопасности TOE, подлежащее оценке. Например, компонент «базовая идентификация» объединяет два функциональных элемента: перечень объектов или информационных типов, для которых функции защиты TOE должны генерировать доказательства аутентификации, и перечень субъектов, которые должны проверять доказательства аутентификации для объектов из первого списка.
Третья частьстандарта содержит каталог компонентов, которые должны быть использованы для стандартного определения гарантий безопасности IT-продуктов и систем. Этот каталог также разбит на классы, семейства и компоненты (аналогично части 2 стандарта). Кроме того, в части 3 приведены критерии оценки безопасности для использования в PP и ST, а также описаны семь уровней оценки «запаса прочности» (Evaluation Assurance Levels - EALs) [2] .
ISO15408 - не догма, а руководство к действию
Таким образом, общие «правила игры» для разработчиков IT-продуктов готовы. Очередь - за потребителями, которым, со своей стороны, следует подготавливать на основе стандарта собственные Профили Защиты продуктов в качестве «руководства к действию» для разработчиков. Первый серьезный шаг в этом направлении на «карточном поле» сделала платежная ассоциация Visa International, которая в мае 1999 г. опубликовала проект документа под названием Visa Smart Card Protection Profile, подготовленный в соответствии с «Общими Критериями» (версия 2.0) и «Общей методологией оценки безопасности информационных технологий» [3] (версия 0.6). VSCPP стал первым документом, предъявляющим требования к безопасности смарт-карточек, операционных систем и приложений для смарт-карточек и одновременно - первым же руководством по оценке параметров безопасности перечисленных выше объектов в соответствии с требованиями Общих Критериев.
Visa Smart Card Protection Profile
Структура Visa Smart Card Protection Profile полностью соответствует требованиям к Профилям Защиты, приведенным в Общих Критериях, и содержит следующие разделы:
· Введение
· Описание Объекта оценки
· Описание внешней среды объекта оценки
· Угрозы безопасности (Security Objectives)
· Требования к безопасности
· Требования к информационной безопасности
· Замечания к Профилю Защиты, учитывающие специфические особенности смарт-карт
· Rationale (логическое обоснование, объяснение)
Следует отметить, что в документе четко определены объекты, безопасность которых подлежит оценке с помощью VSCPP, и специально отмечается, что ни терминальные устройства, ни сетевые интерфейсы, ни дополнительные элементы дизайна смарт-карточек (голограммы, магнитная полоса и т. д.) не подпадают под действие VSCPP.
Во избежание путаницы, в VSCPP дается четкое определение смарт-карты (обязательным атрибутом таких карточек являются микропроцессор и программируемая энергонезависимая память), которая может быть контактной (ISO7816) или бесконтактной (ISO15443). Размеры карточки должны соответствовать ISO7813, хотя карточки меньшего размера - GSM SIM - также могут являться объектами оценки.
Большинство находящихся в обращении смарт-карточек изготовлены по традиционной технологии, когда большая часть программного кода помещается в карточку еще до ее эмиссии. С помощью традиционной технологии могут производиться карточки с «жесткой маской» (hard-mask) и «мягкой маской» (soft-mask). Термин «мягкая маска» традиционно употребляется в отношении карточной операционной системы, размещенной в ROM, и приложений, находящихся в программируемой энергонезависимой памяти. Эта технология обычно применяется в пилотных проектах карточек, по результатам которых в исходный код предположительно придется вносить изменения. В то же время, возможность гибкого изменения программного кода карточки таит в себе и повышенную опасность. Поэтому в случае, когда в пилотном проекте задействовано значительное количество карточек, следует применять адекватные меры их защиты.
Операционная система и коды приложений карточек с «жесткой маской» размещаются в ROM (при этом разделение на OS и код приложений зачастую является условным). Стоимость таких карточек зависит от объема памяти, который строго лимитируется; в результате в карточках с «жесткой маской» поддерживаются лишь минимально необходимые команды, под которые задействуется практически вся память карточки. Излишки памяти необратимо блокируются в процессе персонализации, что дает ощутимый выигрыш в безопасности, но сопровождается потерей гибкости в изменении программного кода.
Новое поколение смарт-карточек имеет гораздо более гибкую операционную систему, которая позволяет добавлять или удалять программный код приложений уже после того, как карточка была эмитирована. Карточки нового поколения могут иметь чиповую операционную систему, карточную операционную систему и дополнительные уровни операционной системы (например, Visa Open Platform) для поддержания специальных свойств продукта. Требования к безопасности таких OS и дополнительных уровней будут отличаться от требований к операционным системам карточек, изготовленных по традиционной технологии. В частности, особое внимание должно уделяться процедурам сертификации и загрузки (удаления) новых (существующих) приложений.
Из сказанного выше становится ясно, что продукты на базе смарт-карточек должны быть четко классифицированы в зависимости от того, какой тип технологии в них используется. В соответствии с этим, для них должны применяться различные процедуры оценки уровня безопасности.
Некоторые из функций обеспечения безопасности с одинаковым успехом могут быть реализованы как программно, так и аппаратно. VSCPP не регламентирует способ реализации таких функций, однако в ST с целью достижения совместимости с PP следует указывать, какой именно способ избран в каждом конкретном случае.
В Профиле Защиты Visa указывается, что для микропроцессорных карточек достаточным является уровень защиты EAL4, дополненный следующими свойствами:
AVA_VLA.3 Оценка уязвимости, анализ уязвимости - умеренная устойчивость
ADV_INT.1 Развитие, содержание TSF, модульная способность к исполнению функций - на среднем уровне
Описание объекта оценки - TOE
В международном стандарте ISO 10202 часть 1 дано понятие жизненного цикла карточки, состоящего из следующих стадий:
Производство интегральной микросхемы и карточки с интегральной микросхемой
· Разработка дизайна полупроводникового компонента и программного обеспечения;
· Производство интегральной микросхемы;
· Сборка микромодуля;
· Установка микромодуля в тело карточки.
Подготовка карточки
· Персонализация карточки;
· Активация Файла данных (CDF).
Подготовка файлов данных приложений (ADF)
· Выделение ресурсов для размещения ADF;
· Персонализация ADF;
· Активация ADF
Использование карточек
· Использование карточек;
· Деактивация ADF;
· Деактивация CDF;
· Реактивация CDF;
· Реактивация ADF.
Прекращение использования
· Прекращение использования ADF;
· Прекращение использования CDF;
· Прекращение использования ключей.
Профиль Защиты относится в первую очередь к двум стадиям - «Использование карточки» и «Прекращение использования карточки». Угрозы безопасности, имеющие место на этих стадиях, должны предотвращаться еще на этапах производства карточек и модулей и подготовки их к вводу в эксплуатацию
Термины CDF and ADF, возможно, не совсем корректно использовать для карточек нового поколения. В этом случае (как и во многих других, когда технологический прогресс опережает прогресс в области стандартизации) следует использовать стандарт ISO 10202.
ПО, которое «зашивается» в ROM, должно предоставляться производителю кристаллов в готовом виде. Дополнительное ПО может быть размещено в программируемой энергонезависимой памяти. В карточках, изготавливаемых традиционным способом, эта операция носит название «инициализации» и является частью подготовки карточки к эксплуатации.
В карточках нового поколения дополнительное ПО может загружаться в PROM на протяжении всего жизненного цикла карточки. В этом случае эмиссия карточек не выделяется в отдельную стадию, хотя и является первым этапом использования карточки.
Типичные приложения для смарт-карточек - платежные (дебетовые, кредитные, «Электронные кошельки»), «жетонные», приложения оплаты проезда в общественном транспорте, оплаты мобильных услуг связи, идентификация (государственных и корпоративных служащих, граждан какой-либо страны или жителей города, студентов и преподавателей университетов, членов клубов и объединений), водительские права, паспорт, а также цифровые сертификаты пользователей, генерируемые с использованием криптографии с открытым ключом и т. д.)., хранилища информации (медицинские и страховые карточки и т. д.), loyalty- и сетевые приложения (хранение идентификаторов и сетевых паролей). Смарт-карты могут содержать как одно, так и несколько приложений, имеющих собственные требования к безопасности, собственный режим работы и т. д. Мультиапликационные карточки могут производиться как по традиционной, так и по новой технологии. Соответственно, требования к безопасности операционных систем и процедур добавления/стирания приложений также будут различаться.
Криптография
В смарт-карточках используются различные криптографические ключи - транспортные, персонализационные, ключи приложений и т д. Поддержка таких ключей должна осуществляться в строгом соответствии с политикой безопасности эмитента и установленными процедурами управления ключами. Криптографические функции могут быть реализованы программно или аппаратно, с использованием различных криптоалгоритмов и ключей разной длины. Многие смарт-карты имеют встроенные криптосопроцессоры, благодаря которым расчеты DES, Triple DES, RSA выполняются быстрее, чем при программной реализации функций шифрования. Следует учитывать, что одни приложения не требуют использования криптографических функций, другие нуждаются в использовании симметричных криптоалгоритмов, третьи - в применении алгоритмов шифрования с открытым ключом. В любом объекте оценки, претендующем на соответствие Профилю защиты Visa, должны поддерживаться криптографические функции в соответствии с международной, промышленной или внутриорганизационной политикой. Это касается и любого приложения, использующего возможности криптографии
Окружение
Условия эксплуатации карточек могут быть самыми разнообразными и в определенной степени зависеть от размещенных на карточках приложений. Однако в любом случае смарт-карточка должна быть защищена от неавторизованного вмешательства держателя с использованием персональных компьютеров и специализированного оборудования.
При оценке уровня защищенности смарт-карточки в соответствии с Профилем защиты Visa делается ряд допущений, касающихся модели злоумышленника. В частности, злоумышленники могут классифицироваться в зависимости от уровня квалификации, имеющихся в их распоряжении ресурсов и мотивации, на пользователей и администраторов.
Пользователи обладают необходимыми правами доступа к информации, которой управляет объект оценки.
Администраторы - это пользователи, наделенные полномочиями оперативно управлять защитными свойствами объекта оценки.
[1] В сентябре 1999 г. микрочип Infineon с операционной системой MULTOS получил сертификат ITSEC уровня E6.
[2] Концепция уровней «запаса прочности» была разработана с тем, чтобы результаты предыдущих оценок уровня безопасности информационных продуктов (TCSEC, ITSEC, and CTCPEC) оставались действительными (например, EAL 2-7 соответствуют TCSEC C2-A1).
[3] Common Methodology for Information Security Evaluation (CEM) Version 0.6, 99/008, January
1999.