Подходы к обеспечению безопасности данных участников NFC-экосистемы

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

Напомню, существует несколько вариантов расположения Элемента Безопасности (далее ЭБ, в английском варианте Secure Element, или сокращенно SE):

- встроенный в телефонный аппарат (когда чип ЭБ является неотъемлемой частью телефонного аппарата)

- ЭБ в виде µSD-карты

- ЭБ в виде специализированного чехла

- ЭБ в виде UICC-карты, специальным образом подготовленной

О последнем варианте, как о наиболее стандартизированном и отработанном, и пойдет речь в данной статье.

У ЭБ есть владелец (SE Issuer). В случае с UICC-картой – это оператор сотовой связи (Mobile Network Operator, MNO). NFC-услуги оказывает Поставщик Услуг (Service Provider, SP). Поставщик услуг является Эмитентом или Поставщиком Приложения (Application Provider).

Как же обеспечить сосуществование данных различных участников NFC-экосистемы на одном ЭБ? Каким образом предоставить возможность загрузки и персонализации приложений, управления состоянием и данными приложений разных участников на одном ЭБ с одной стороны, а также обеспечить независимость и безопасность каждого из участников, с другой?

На эти вопросы есть ответы в стандартах консорциума GlobalPlatform.

Стандарты этой организации давно знакомы в банковской сфере. Современные банковские карты, равно как и NFC UICC-карты, поддерживают стандарты GlobalPlatform.

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

Поговорим об одном из аспектов, описываемых спецификацией GlobalPlatform Card Specification – о Доменах Безопасности (Security Domain).

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

Существует три основных типа доменов безопасности:

• Домен Безопасности Эмитента (Issuer Security Domain, ISD). Этот домен один, обязателен на карте и является самым привилегированным. С его помощью можно выполнять загрузку, установку, экстрадицию и удаление любого приложения на карте;
• Дополнительные Домены Безопасности (Supplementary Security Domain, SSD). Необязательные домены безопасности, которых может быть на карте много и которые предназначены для использования поставщиками приложений.
• Домен Безопасности Доверенной Стороны (Controlling Authority Security Domain, CASD). Необязательный домен безопасности, являющийся SSD. Служит для проверки источника и целостности загружаемых на карту приложений, а также отвечает за загрузку начальных значений ключей SSD.

Домены имеют иерархическую древовидную структуру. Всегда имеется Домен Безопасности Эмитента. У него может быть несколько Дополнительных Доменов Безопасности, у каждого из которых в свою очередь также может быть несколько подчиненных Дополнительных Доменов Безопасности.

Структуру доменов безопасности можно представить в виде подъезда многоквартирного дома. У дома (подъезда) есть владелец – это Домен Безопасности Эмитента. Квартиры в подъезде – это Дополнительные Домены Безопасности. Владелец подъезда знает, сколько квартир у него есть, какие из них свободные, какие занятые. У него есть ключи от подъезда. Он может предоставлять доступ к свободным квартирам новым участникам.

Владелец квартиры обладает своими ключами. Только он имеет доступ к своей квартире. Владелец подъезда при этом НЕ обладаем неким «супер-ключом» и НЕ может попасть в квартиры участников. Владелец подъезда может наделить владельца квартиры различными правами. В частности, правом на создание комнат в квартире со своими правами, но не бОльшими, чем имеются у самого владельца квартиры. Владелец квартиры может иметь в своей квартире несколько комнат, которые будут закрываться отдельными ключами.

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

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

Дополнительные Домены Безопасности могут быть созданы и персонализированы своими секретными ключами непосредственно во время эмиссии карты. В этом случае, ключи каждого такого Домена Безопасности генерируются и хранятся под защитой Аппаратного Модуля Безопасности (Hardware Security Module, HSM) сертифицированного Бюро Персонализации, обеспечивающего эмиссию.

Такой подход к организации иерархии Доменов Безопасности карты вполне применим к небольшим проектам, когда либо ограничен срок жизни карт (например, при запуске «пилота»), либо ограничено количество участников (Поставщиков Приложений), потенциально имеющих доступ к содержимому карты.

Для более долгосрочных и масштабных (с точки зрения количества участников) проектов применима другая конфигурация ЭБ, когда во время эмиссии на карте создаётся только Домен Безопасности Эмитента и Домен Безопасности Доверенной Стороны. Дальнейшее управление содержимым карты (создание Дополнительных Доменов Безопасности, их персонализация ключами, а также загрузка и персонализация приложений) осуществляется «по-воздуху» (Over-The-Air, OTA), благодаря тому, что ЭБ является SIM-картой, установленной в телефон абонента. В этом процессе, кроме самого инициатора изменения содержимого карты (т.е. Поставщика Приложения), обязательно будут участвовать два посредника: Эмитент и Доверенная Сторона. Роль Эмитента состоит в безопасной отправке OTA-сообщений на карту (с использованием соответствующего сетевого оборудования), а роль Доверенной Стороны заключается в обеспечении конфиденциальности передаваемых данных (ключей создаваемых SSD), т.е. открытые значения ключей нового SSD не будут доступны никому, кроме Поставщика Приложения.

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

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

Консорциум GlobalPlatform предлагает два сценария выполнения этих действий. В первом, сама карта генерирует ключ Домена Безопасности и затем отправляет его Поставщику Приложения в зашифрованном виде (pull-модель). Во втором, Поставщик Приложения выполняет генерацию ключей и отправляет их на карту также в зашифрованном виде (push-модель). В обоих случаях Доверенная Сторона обеспечивает аутентичность передаваемых с/на карту сообщений. В зависимости от используемого сценария, а также схемы шифрования данных (симметричная или асимметричная), ключевая информация в открытом виде будет доступна либо только Поставщику Приложения, либо ещё и Доверенной Стороне (но не Эмитенту, обеспечивающему только OTA-транспортировку зашифрованных сообщений c/на карту).

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

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

Модели прописки жильцов в квартиах:

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

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

Основным критерием выделения различных режимов работы карты является степень доверия между Эмитентом карты и Поставщиком Приложения. Кроме того, каждый режим работы карты допускает разделение процессов загрузки и установки приложений и их персонализации (т.е., собственно, управление содержимым карты и персонализация могут быть разделены между различными участниками NFC-экосистемы). При этом, вне зависимости от выбранного режима работы карты, персонализационные данные приложения всегда защищены Доменом Безопасности, с которым связано это приложение (т.е. Эмитент получить к ним доступа не может – его задача заключается в OTA-транспортировке команд и/или в предоставлении права условного (подпись каждой команды) или безусловного управления содержимым карты).

Теоретически допускается также наличие двух OTA-платформ – у Эмитента и у Поставщика Приложения (либо его доверенного представителя, называемого TSM). Этот факт также позволяет выделять различные варианты управления содержимым карты и персонализации приложений в рамках одного режима.

Режимы работы карты и их варианты.

• Простой режим (Simple Mode). Отправкой команд управления содержимым карты и персонализацией занимается Эмитент карты (данные персонализации защищены). У данного режима возможен вариант, когда Поставщик Приложения (либо его TSM) имеет собственную OTA-платформу, с которой осуществляется только персонализация приложения (т.е. Эмитент только загружает, устанавливает или удаляет приложения, но не персонализирует их).
• Режим доверенного управления (Delegated Management Mode). Данный режим подразумевает наличие у Поставщика Приложения (либо его TSM) своей OTA-платформы, при помощи которой осуществлятся управление содержимым карты и персонализация приложений. Однако каждая команда, отправляемая Поставщиком Приложения на карту должна быть заверена подписью Эмитента – только в этом случае она будет обработана картой.
• Режим авторизованного управления (Authorized Mode). Данный режим отличается от предыдущего тем, что Эмитент предоставляет Поставщику Приложения (его Домену Безопасности) безусловное право на управление содержимым карты (т.е. необходимости в подписи каждой команды нет).

Нельзя недооценить роль третьей доверенной стороны, которая служит связующим звеном между участниками NFC-экосистемы, т.е. между операторами связи – владельцами ЭБ и Поставщиками Услуг.

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

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

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