Вопросы идентификации и аутентификации при разработке мультиаппликационных карт

Понятие "мультиаппликационная карта" стало часто употребляться несколько лет назад. «Аппликация» (application) в переводе с английского языка означает «приложение» («прикладная программа»). Если одна карта работает не с одним (например, платёжным), а с несколькими приложениями, такая карта называется мультиаппликационной.

Историческая необходимость в мультиаппликационных картах появилась в связи с тем, что число приложений, с которыми работает значительная часть пользователей, постоянно растёт и в среднем составляет уже пять и более прикладных систем. Система разделения доступа к приложению, как минимум, требует пароля. Современные системы управления доступом к модулям программ и особенно конфиденциальным данным строятся на базе инфраструктуры открытых ключей. Известно, что самым распространённым способом организации доступа до сих пор является пара «логин - пароль», однако одна из лучших в плане безопасности - это технология организации доступа с применением цифровых сертификатов, которые выдаст доверенный удостоверяющий центр на основе открытого ключа пользователя. При этом в качестве учётной записи пользователя - его идентификатора для доступа (в простейшем случае - логина) - используются определенные поля цифрового сертификата Х.509, а в качестве секрета, применяющегося для подтверждения подлинности предъявленного идентификатора, - закрытый ключ, который пользователь обязан хранить в тайне. Разработчики приложений всё чаще применяют именно такой способ организации доступа пользователей в силу его высокой безопасности. При этом для хранения закрытого ключа пользователя в большинстве случаев применяются микропроцессорные смарт-карты или USB-ключи. Чтобы не носить с собой несколько носителей закрытых ключей и соответствующих сертификатов (которые также помещают на смарт-карту), возникла идея использования одной смарт-карты для нескольких приложений сразу, тем более что около 10 лет назад на рынке появились высокопроизводительные смарт-карты, способные не только хранить закрытые ключи, но и генерировать их внутри защищённого чипа. В этой же смарт-карте могут храниться цифровые сертификаты для доступа к приложению или пароль (если приложение пока не использует инфраструктуру открытых ключей). Такая же идея объединения средств доступа к нескольким приложениям лежит в основе проекта универсальной электронной карты (УЭК). Основой организации систем управления доступом к приложениям является решение задач идентификации и аутентификации пользователей.

Идентификация и аутентификация

Далеко не все приложения требуют аутентификации пользователя. Имеется целый ряд приложений, для которых достаточно идентификации пользователя, а некоторые из них (например, оплата проезда) могут использовать только идентификацию самой карты (например, по её номеру) и наличия на ней достаточных предоплаченных средств. Соответственно, для процессов идентификации и аутентификации различного уровня строгости применяются и разные технологии. На рис. 1 представлены широко используемые средства идентификации и аутентификации с точки зрения применяемых технологий. Например, в упомянутом примере оплаты проезда в последнее время чаще всего применяется технология RFID (Radio Frequency Identification Device —идентификация устройства на основе использования радиочастот).

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

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

Безусловно, самым безопасным способом аутентификации является применение технологии электронной подписи (третья строка в таблице). Преимущество применения закрытого ключа в качестве аутентификатора очевидно: не требуется знание значения ключа подписи на серверной стороне, достаточно лишь владеть открытым ключом и уведомлением о способе подтверждения подлинности. Это существенно повышает уровень защищённости процесса аутентификации, однако организация доступа с применением цифровых сертификатов доступа и закрытого ключа электронной подписи может иметь свои подуровни доверия, зависящие от способов формирования и хранения закрытого ключа. Так, закрытый ключ (ключевая пара) может быть сформирован по технологии усиленной неквалифицированной подписи или с помощью технологии усиленной квалифицированной подписи. Также надо учитывать способы формирования и хранения ключевой пары. Дело в том, что закрытый ключ может быть перенесён в смарт-карту после того, как ключевая пара сгенерирована программным крипто сервис-провайдером в оперативной памяти компьютера. При другом, более безопасном способе, ключевой материал формируется в защищённой памяти чипа смарт-карты или USB-ключа. Однако чипы могут быть разные, например специально спроектированные, произведенные и сертифицированные по различным требованиям безопасности. Самым безопасным вариантом является применение чипов класса Secure by Design (безопасные по условиям проектирования), сертифицированных по различным уровням требований CAST и Common Criteria (например, самым распространённым требованием на Западе является наличие у устройства генерации ключевого материала сертификата EAL4+).

Микропроцессорная смарт-карта для аутентификации в данном случае применяется в двух вариантах, зависящих от перечисленных выше вариантов способа формирования ключевой пары. Самым распространенным на сегодня в России является способ генерации ключевой пары с помощью программной реализации криптографических алгоритмов в виде CSP (Crypto Service Provider - крипто сервис-провайдер) в оперативной памяти компьютера. Наиболее распространенным крипто сервис-провайдером является «КриптоПро CSP». Вторым способом является генерация ключевой пары непосредственно внутри защищённого чипа смарт-карты. Такие устройства, именуемые SSCD (Secure Signature Creation Device - устройства, генерирующие цифровую подпись), известны с конца двадцатого века.

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

Более защищённой технологией формирования ключевой пары является выполнение этой процедуры внутри специально спроектированного чипа смарт-карты. Такие устройства известны уже более 10 лет и вошли в целый ряд нормативно-правовых документов на Западе (в том числе в стандарты) как SSCD.

Классификацию по уровням доверия («уровням гарантий», «уровням надёжности») лучше всего вести на основе простой шкалы по аналогии с установленными № 63-Ф3 видами электронной подписи: простая, усиленная и строгая. Принцип классификации аутентификации по уровням доверия также должен базироваться на анализе рисков от атак на взаимодействующие стороны и сам процесс взаимодействия. Согласно данным работы [ 1 ], данная классификация должна учитывать применяемые технологии аутентификации, а также обеспечение целостности и конфиденциальности аутентификационной информации. Приведем краткое описание трех уровней доверия аутентификации, предложенных в работе [2].

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

Усиленная аутентификация базируется на более стойкой к атакам технологии OTP (One-Time-Password, одноразовый пароль), при которой для каждого запроса на доступ используется новый пароль, действительный только для одного входа в систему. В зависимости от конкретной реализации применение ОТР может существенно повысить безопасность аутентификации. Среди самых распространенных схем с ОТР являются системы аутентификации, в которых для доступа пользователя одноразовый пароль одновременно используется вместе с многоразовым паролем. Технологии генерации ОТР могут быть различными, наиболее часто употребляются схемы выработки одноразовых паролей «по событию» и «по времени». Стойкость ОТР определяется вектором инициализации аутентификатора [3].

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

• односторонней, типичным примером которой является однонаправленный протокол SSL, в котором требуется проверка сертификата только на стороне клиента;
• двухсторонней (например, вариант SSL, когда проверяются сертификаты серверной и клиентских сторон);
• трёхсторонней, когда к двум сторонам добавляется доверенная третья сторона (например, широко применяемый в корпоративных системах протокол Kerberos).

Для наглядности рассмотренная классификация представлена на рис. 2.

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

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

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

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

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

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

Влияние стандартов на появление и развитие мультиаппликационных карт трудно переоценить. Гносеологию карточных стандартов можно проследить с 1985 года, когда были приняты ISO 7810 по физическим характеристикам идентификационных карт и стандарт ISO 7811, определяющий технологии записи на магнитную полосу (часть 1) и эм- боссирования (часть 2). В 1986 году вступили в действие два стандарта: ISO 7812, описывающий систему нумерации и процедуры регистрации идентификаторов эмитентов, и ISO 7813, задающий стандарт физических параметров карт (толщину, скругление углов и т. д.) для банков и являющийся развитием стандарта ISO 7810.

Весьма важную роль в развитии современных смарт-карт сыграло появление в 1987 году первой (базовой) версии семейства стандартов ISO 7816 (с последующими доработками этого стандарта, принятыми в 1998 и 2003 годах), описывающих спецификации конструкции и применения электронных идентификационных карт с контактами. В конце 1980-х годов появились микросхемы для пластиковых карт, имеющих архитектуру однокристальных микро- ЭВМ (микроконтроллеров). Появление микроконтроллеров потребовало в 1989 году разработки третьей части стандарта ISO 7816, описывающего электрические параметры интерфейса и некоторые принципы установления связи для карт со считывателем (ридером) по асинхронному интерфейсу. Наличие микропроцессора позволило использовать хорошо зарекомендовавшие себя в вычислительной технике асинхронные протоколы семейства UART (Universal Asynchronous Receiver/ Transmitter).

Кроме микропроцессора, микрочип карты включает в себя постоянную память (ROM) и электрически перезаписываемую энергонезависимую память (EEPROM) (рис. 3). ROM содержит следующее системное программное обеспечение [4]:

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

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

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

• GSM - приложение для мобильных телефонов (1990 год);
• EMV - платёжное приложение для банковских карт (1995 год);
• HIPPAA - приложение для медицинского страхования (1996 год).

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

В 1996 году появился индустриальный стандарт PC/SC (Personal Computer/Smart Card), специфицирующий интеграцию смарт-карт в компьютерную инфраструктуру. В настоящее время данный стандарт поддерживается всеми основными операционными системами для персональных компьютеров: Microsoft Windows, Linux, Mac OS X. Поставщики ридеров разрабатывают специальный PC/SC-драйвер для своих устройств, который интегрируется в операционную систему персонального компьютера, в результате у разработчика прикладного программного обеспечения отпадает необходимость в настройке программы под конкретный тип ридера.

Несмотря на бурное развитие смарт-карт и стандартов их работы, микропроцессорные карты тех лет имели ещё один достаточно серьёзный недостаток. Операционные системы каждого типа карты характеризовались фиксированным набором приложений, записанных в ROM, и имели уникальный набор команд управления жизненным циклом карты и персонализации (проблема так называемой «нативной» операционной системы). В то время ещё не было разработано чётких и безопасных механизмов изменения функциональности карты после её эмиссии. Это создавало большие трудности при переходе системы от использования одного типа карт на другой и настройке процесса электрической персонализации.

Основные усилия для решения данной проблемы были предприняты в конце 1990-х - начале 2000-х годов. На рынке появились так называемые мультиаппликационные (multiapplication) карточные платформы, которые позволяли разрабатывать небольшие приложения и загружать их в карту, размещая в EEPROM. К таким платформам можно отнести Java Card, MULTOS, WfSC (Windows for Smart Card), Smart-card.NET, Basic Card. В настоящее время наибольшее распространение получили Java-кэрты Global Platform.

Широкое применение спецификаций открытого стандарта Global Platform сыграло немаловажную роль в появлении мультиаппликационных карт. Он - результат некоммерческого партнёрства, организованного в 1999 году в целях создания стандарта, регламентирующего взаимодействие смарт-карт с различными устройствами, обеспечивая при этом безопасную обработку и хранение данных. Этот стандарт первоначально назывался Open Platform. По мере подключения к работе над ним все большего количества производителей и других платёжных систем, включая American Express, JCB, MasterCard International, Visa, эта инициатива переросла в международное объединение, получившее название «Глобальная платформа» (Global Platform). В настоящее время к Глобальной платформе присоединилось более 100 разработчиков, её влияние в мире постоянно растёт. По итогам проведённого «Евро- смарт» исследования, из поставленных 7 млрд безопасных чипов, выпущенных в мире в 2012 году, более 2,6 млрд выполнены по технологии Global Platform.

Стандарт EMV - международный стандарт для операций по банковским картам с чипом. Этот стандарт разработан совместными усилиями компаний Europay, MasterCard и Visa в целях повышения уровня безопасности финансовых операций. Основное отличие для пользователя карты стандарта EMV - это требование ввода PIN-кода при проведении любого платежа через терминал (например, в магазинах, ресторанах).

Стандарт EMV определяет физическое, электронное и информационное взаимодействие между банковской картой и платёжным терминалом для финансовых операций. Как уже упоминалось, существуют стандарты, основанные на ISO/1EC 7816 для контактных карт, также существуют и стандарты ISO/IEC 14443 для бесконтактных карт.

В качестве универсальной программной среды сообщество Global Platform остановило свой выбор на платформе Java Card - технологии, дающей возможность безопасным образом устанавливать и исполнять небольшие Java-приложения (апплеты) на смарт-картах и других устройствах с весьма ограниченным объёмом памяти. Java Card, среди прочих известных платформ линейки Java, является наименее требовательной к ресурсам вычислительного устройства, но при этом обладает наименьшими возможностями. Эта платформа позволяет поставщику программировать устройства и делать их адаптированными под конкретное применение. Технология Java Card широко используется для производства SIM-карт и банковских платёжных карт.

Стандарты для безопасной установки апплетов Java Card на устройства разрабатывает организация по стандартизации - Global Platform.

Платформа Java Card

В основу идеологии Java Card заложено два основных принципа [5]: портируемость и безопасность.

Портируемость. Java Card описывает стандартную среду исполнения на смарт-картах для обеспечения возможности одному и тому же приложению работать на различных устройствах. Как и в более сложных платформах Java, это достигается комбинацией виртуальной машины (Java Card Virtual Machine) и стандартизированной библиотеки классов, что позволяет апплету значительно абстрагироваться от особенностей конкретных моделей смарт-карт. Однако это не даёт полной гарантии переносимости приложения на любую смарт-карту, поскольку остаются такие факторы, как объём памяти, производительность или доступность особых интерфейсов (например, коммуникационных протоколов или криптографических алгоритмов).

Безопасность. Безопасность данных на смарт-картах была одним из основных приоритетов при разработке платформы Java Card. Она обеспечивается различными свойствами платформы: защитой данных, экраном апплетов, криптографией и механизмом апплетов.

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

Экран апплетов (Application Firewall). Несколько апплетов могут быть активными одновременно, однако они изолированы по модели «песочницы»: приложению выделяется контекст, к данным которого оно имеет доступ. Данные других приложений ограждены экраном. Для обеспечения совместной работы нескольких приложений есть механизм переключения контекстов, который выполняется через процесс, контролируемый виртуальной машиной.

Криптография. Поддерживаются популярные алгоритмы шифрования, в числе которых DES, 3DES, AES, RSA. Также поддерживаются другие криптографические сервисы: цифровые подписи, генерирование электронных ключей и обмен ими.

Механизм апплетов. Апплет Java Card - это, по сути, конечный автомат, который обрабатывает входящие команды и отвечает, посылая данные или возвращая информацию о статусе.

При программировании учитываются ограничения, накладываемые малыми ресурсами микропроцессорной карты. Для создания апплета используются специальные библиотеки классов Java Card API, поставляемые компанией Sun Microsystems. После компиляции стандартным компилятором получается набор class-файлов, исполняемых на персональном компьютере стандартной виртуальной машиной. Для загрузки апплета на карту набор «обычных» class-файлов необходимо преобразовать в так называемый САР-файл (converted applet) с помощью специальной программы конвертора.

САР-файл загружается в смарт- карту, приложение инсталлируется и далее исполняется интерпретатором. В дополнение к преобразованному байт-коду конвертор создает экспортный файл, описывающий доступные интерфейсы сконвертированного класса. Все опции языка программирования, которые не поддерживаются спецификацией Java Card, удаляются при конвертировании.

Собственно САР-файл содержит двоичное представление классов в пользовательском пакете. Фактически этот файл представляет собой Java-архив (.jar файл). В архиве содержится информация о классах, выполняемый байт-код, информация о связывании и т. п. Байт-код, определяемый САР, построен на основе стандартного байт-кода Java и оптимизирован для исполнения в условиях ограниченных ресурсов смарт- карты. САР-файл определяет двоичную совместимость приложений на платформе Java Card между картами различных производителей.

Спецификации на виртуальную машину Java не определяют процесс загрузки, инсталляции и удаления апплетов на карте. Данные процедуры описывают стандарты Global Platform. Схема взаимодействия системы обслуживания и Java-карты Global Platform не сильно отличается от аналогичной схемы для микропроцессорных карт. Это и неудивительно, так как периферийное оборудование системы должно обслуживать все карты стандарта ISO 7816 (части 1-4), к которым относятся и карты Global Platform. Основное отличие заключается в наличии в ROM микроконтроллера специальных программных модулей: виртуальной Java-машины и модуля Global Platform. Виртуальная Java- машина обеспечивает безопасное выполнение апплетов, загруженных в ROM или EEPROM, а модуль Global Platform обеспечивает безопасную загрузку, инсталляцию, запуск и, если необходимо, удаление апплетов. Первоначально «чистая» карта не содержит никаких специальных приложений и может выполнять исключительно команды, необходимые для администрирования карты, безопасной загрузки и инсталляции апплетов.

Очень важной особенностью Java-сapт является их способность создавать несколько экземпляров приложений (instance), записанных в ROM или в EEPROM. В случае создания экземпляра выделяются совершенно независимые блоки памяти для хранения данных экземпляра, а вот код приложения используется один и тот же. Данное обстоятельство позволяет существенно экономить память карты, когда различные службы используют приложения сходной функциональности. Отличительная особенность - разделение платформы между смарт- картой и настольным компьютером как в пространстве, так и во времени. Платформа Java Card включает три составные части:

• виртуальная машина Java Card Virtual Machine (JCVM): реализация JCVM определяется спецификацией Java Card Virtual Machine Specification, регламентирующей подмножество языка Java и виртуальную машину для смарт-карт;
• среда исполнения Java Card Runtime Environment (JCRE): реализация JCRE определяется спецификацией Java Card Runtime Environment Specification, регламентирующей режимы работы JCRE, включая управление памятью, апплетами, а также выполнения других функций времени исполнения;
• программный интерфейс Java Card Application Programming Interface (API): определяется спецификацией APIs for the Java Card Platform, описывающей набор базовых и дополнительных пакетов и классов Java для программирования смарт- карт.

Указанные спецификации являются составными частями более общей спецификации - Java Card Platform Specification2.

Реализация среды исполнения Java Card Runtime Environment отвечает cпецификациям;

Java Card Platform Specification 2.2.23, разработанной компанией SUN Microsystems;

Global Platform 2.2.14, отвечающей за интероперабельность и продвигающей глобальную инфраструктуру смарт-карт.

Спецификация Java Card Platform Specification 2.2.2 адаптирует (урезает) среду Java под возможности исполнения на смарт-карте как на устройстве, имеющем ограниченные аппаратные ресурсы, а спецификация GlobalPlatform 2.2.1 регламентирует управление исполняемыми приложениями Java. Максимальное число приложений, доступ к которым осуществляется с помощью апплетов, определяется размером свободной памяти для записи апплетов.

На рис. 4 приводится типовая архитектура операционной системы основного чипа современной муль- тиаппликационной смарт-карты.

Из представленного рисунка видно, что основное достоинство платформы Java Card - возможность защищённого доступа к приложениям, написанных на языке Java (Java-апплетов). Использование этой платформы позволяет расширять функциональность смарт-карты за счёт загрузки дополнительных апплетов (например, апплета, реализующего российские криптографические алгоритмы, или приложений, реализующих дополнительные функции: «электронного кошелька» и т. п.). Язык Java доступен многим программистам, это позволяет программировать апплеты в смарт-карты практически для любого применения. Главное, соблюдать при этом требования открытых стандартов.

Современные ОС осуществляют функции управления системными ресурсами смарт-карты. Платформа Java Card состоит из нескольких компонентов в соответствии с механизмами, определенными исполняемой средой Java Card Runtime Environment (JCRE). Для каждого апплета Card Manager различает разные значения AID (Applet Identification Number). AID - уникальный идентификатор апплета, который позволяет однозначно выделить его среди других апплетов в устройстве. AID задаётся в параметрах команды установки апплета и хранится в исполняемой среде Java Card. AID представляет собой байтовый массив, состоящий из двух самостоятельных частей. Первая часть длиной 5 байт называется RID (Resource Identification Number - идентификатор ресурса) и выделяется для разработчика Международной организацией по стандартизации (ISO). Вторая часть имеет переменную длину и называется PIX (внутреннее расширение идентификатора). Поле PIX может иметь длину от 0 до 11 байт и задаётся самим разработчиком апплета. Соответственно, общий размер AID составляет от 5 до 16 байт.

Мультиаппликационная карта - средство доступа к различным приложениям

Условно можно разделить приложения, с которыми должна работать смарт-карта, на несколько классов, зависящих от требований безопасности и, соответственно, от применяемых механизмов аутентификации. Как уже упоминалось выше, доступ к некоторым приложениям не требует аутентификации. Ярким примером является транспортное приложение, для которого достаточно идентифицировать карту (а не её владельца) и определить, достаточно ли средств на карте для оплаты проезда. Для работы с транспортными приложениями чаще всего используются технологии RFID (Radio Frequency Identification Device), основанные на бесконтактном способе обмена информацией на расстояниях от нескольких миллиметров до десятков сантиметров [6]. Пластиковая карта со встроенной антенной и RFID-меткой является пассивным электромагнитным контуром, при внесении карты в область излучения в заданном диапазоне частот (например, 125 КГц) в контуре возникает ток, который используется для обмена информацией между приёмником и картой. Наибольшее распространение в Российской Федерации в качестве транспортных карт получили пластиковые карты Mifare.

Интеграция доступа к транспортному приложению в мультиаппликационную карту производится механическим способом: в стандартную пластиковую карту Mifare имплантируется микропроцессорный чип. Принцип интеграции показан на рис. 5.

Видно, что оба контура (смарт- карточный чип и RFID) гальванически развязаны и расположены в пластиковой карте независимо друг от друга.

По такому же принципу производится интеграция с RFID-метками систем контроля и управления доступом (СКУД) в помещения. По опыту производства в одной пластиковой карте можно разместить до двух RFID-меток. Теоретически (и несложно технически), в этой же карте можно разместить ещё 2 чипа, но этого не делают, прежде всего, из эстетических соображений. Чаще всего, кроме чипа и RFID-метки (меток), на обратной стороне смарт- карты размещают магнитную полосу (рис. 6) и при необходимости штрих-код.

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

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

• идентификация в проходной по визуальным параметрам (наличие ЕЭП установленного образца, сличение нанесённой на смарт- карту фотографии с лицом субъекта, соотнесение разрешённого времени прохода на территорию с временем проверки, наличие/отсутствие разрешения на пронос портфеля и т. п.);
• визуальная или автоматическая идентификация в проходной по биометрическим параметрам, хранящимся в чипе ЕЭП (фотография владельца, отпечатки пальцев и т. п.);
• наличие в ЕЭП радиометки (RFID) для автоматического контроля и управления доступом в помещения (СКУД), расположенные на территории предприятия (современные СКУД позволяют не только программировать определенные разрешённые маршруты перемещения сотрудника, но и перекроссировать телефонные вызовы при входящем звонке на штатное рабочее место в то помещение, в котором в данный момент находится сотрудник);
• возможность оплаты обедов, проезда, парковки и других услуг;
• идентификация и аутентификация владельца единого электронного пропуска при доступе к ЭВМ, корпоративной информационной сети и информационным ресурсам;
• организация минимально-достаточного для выполнения служебных обязанностей доступа пользователя только к разрешённым приложениям и конфиденциальным данным;
• наличие персонального средства формирования электронной подписи внутри чипа ЕЭП;
• организация защищённого доступа к разрешённым web-порталам и облачным сервисам;
• возможность обеспечения защищённого удалённого доступа к информационной системе.

Введение ЕЭП может упростить основные процедуры доступа сотрудникам предприятия. Управление доступом может стать более прозрачным для органов контроля и администраторов безопасности, а также существенно снизить вероятность реализации атак злоумышленников повысить уровень защищённости активов предприятия.

ЛИТЕРАТУРА

1. Сабанов А. Г. Аутентификация как часть единого пространства доверия / Электросвязь. 2012. № Я, с. 40-44.
2. Сабанов А. Г. Об оценке рисков удалённой аутентификации как процесса / Электросвязь. 2013, № 4, с. 27-32.
3. Сабанов А. Г. Обзор технологий идентификации и аутентификации /Документальная электросвязь. 2006, № 17, с. 23-27.
4. Аваков/1 Ю. М., Воронин А. С. и др. Платёжные карты: бизнес-энциклопедия - М.: Мар- кет ДС, 2008. - 760 с. илл. и вкп.
5. Дьяков О. Н. Современные микропроцессорные Java-карты Global Platform и системы управления приложениями Материалы компании ИНПАС IЭлектронный ресурс]. - Режим доступа: www.inpas.ru.
6. Сабанов А. Г. Доверенные сервисы идентификации и аутентификации пользователей для публичных облаков / Connect! Мир связи. № 3, 2013, с. 92-95.