СПОСОБЫ И УСТРОЙСТВО ДЛЯ КРУПНОМАСШТАБНОГО РАСПРОСТРАНЕНИЯ ЭЛЕКТРОННЫХ КЛИЕНТОВ ДОСТУПА

Приоритет

Данная заявка притязает на приоритет заявки на патент США с порядковым №13/767593, поданной одновременно с настоящей заявкой 14 февраля 2013 г. и озаглавленной "METHODS AND APPARATUS FOR LARGE SCALE DISTRIBUTION OF ELECTRONIC ACCESS CLIENTS", которая притязает на приоритет предварительной заявки на патент США с порядковым №61/598819, поданной 14 февраля 2012 г. и озаглавленной "METHODS AND APPARATUS FOR LARGE SCALE DISTRIBUTION OF ELECTRONIC ACCESS CLIENTS", при этом каждая из вышеупомянутых заявок полностью включается в этот документ путем ссылки.

Родственные заявки

Данная заявка имеет отношение к находящимся в процессе одновременного рассмотрения заявкам на патент США того же заявителя с порядковыми №№13/457333, поданной 26 апреля 2012 г. и озаглавленной "ELECTRONIC ACCESS CLIENT DISTRIBUTION APPARATUS AND METHODS", 13/464677, поданной 4 мая 2012 г. и озаглавленной "METHODS AND APPARATUS FOR PROVIDING MANAGEMENT CAPABILITIES FOR ACCESS CONTROL CLIENTS", 13/095716, поданной 27 апреля 2011 г. и озаглавленной "APPARATUS AND METHODS FOR DISTRIBUTING AND STORING ELECTRONIC ACCESS CLIENTS", 13/080558, поданной 5 апреля 2011 г. и озаглавленной "APPARATUS AND METHODS FOR CONTROLLING DISTRIBUTION OF ELECTRONIC ACCESS CLIENTS", 12/952082, поданной 22 ноября 2010 г. и озаглавленной "WIRELESS NETWORK AUTHENTICATION APPARATUS AND METHODS", 12/952089, поданной 22 ноября 2010 г. и озаглавленной "APPARATUS AND METHODS FOR PROVISIONING SUBSCRIBER IDENTITY DATA IN A WIRELESS NETWORK", 13/183023, поданной 14 июля 2011 г. и озаглавленной "VIRTUAL SUBSCRIBER IDENTITY MODULE DISTRIBUTION SYSTEM", и 12/353227, поданной 13 января 2009 г. и озаглавленной "POSTPONED CARRIER CONFIGURATION", 13/093722, поданной 25 апреля 2011 г. и озаглавленной "APPARATUS AND METHODS FOR STORING ELECTRONIC ACCESS CLIENTS", 13/109851, поданной 17 мая 2011 г. и озаглавленной "METHODS AND APPARATUS FOR ACCESS CONTROL CLIENT ASSISTED ROAMING", 13/079614, поданной 4 апреля 2011 г. и озаглавленной "MANAGEMENT SYSTEMS FOR MULTIPLE ACCESS CONTROL ENTITIES", 13/111801, поданной 19 мая 2011 г. и озаглавленной "METHODS AND APPARATUS FOR DELIVERING ELECTRONIC IDENTIFICATION COMPONENTS OVER A WIRELESS NETWORK", 13/080521, поданной 5 апреля 2011 г. и озаглавленной "METHODS AND APPARATUS FOR STORAGE AND EXECUTION OF ACCESS CONTROL CLIENTS", 13/078811, поданной 1 апреля 2011 г. и озаглавленной "ACCESS DATA PROVISIONING APPARATUS AND METHODS", 13/287874, поданной 2 ноября 2011 г. и озаглавленной "METHODS AND APPARATUS FOR ACCESS DATA RECOVERY FROM A MALFUNCTIONING DEVICE", 13/080533, поданной 5 апреля 2011 г. и озаглавленной "SIMULACRUM OF PHYSICAL SECURITY DEVICE AND METHODS", и 13/294631, поданной 11 ноября 2011 г. и озаглавленной "APPARATUS AND METHODS FOR RECORDATION OF DEVICE HISTORY ACROSS MULTIPLE SOFTWARE EMULATION", при этом каждая из вышеупомянутых заявок полностью включается в этот документ путем ссылки.

1. Область техники, к которой относится изобретение

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

2. Описание предшествующего уровня техники

Контроль доступа необходим для защищенной связи в большинстве систем беспроводной радиосвязи известного уровня техники. В качестве примера одна простая схема контроля доступа могла бы содержать: (i) проверку идентичности взаимодействующей стороны и (ii) предоставление некоторого уровня доступа в соответствии с проверенной идентичностью. В контексте типовой сотовой системы (например, Универсальной системы мобильных телекоммуникаций (UMTS)) контроль доступа определяется клиентом контроля доступа, называемым Универсальным модулем идентификации абонента (USIM), исполняющимся на физической Универсальной карте с интегральной схемой (UICC) (также называемой "SIM-картой"). Клиент контроля доступа USIM аутентифицирует абонента в сотовой сети UMTS. После успешной аутентификации абоненту разрешен доступ к сотовой сети. При использовании в дальнейшем термин "клиент контроля доступа" в целом относится к логической сущности, воплощенной либо в аппаратных средствах, либо в программном обеспечении, подходящих для контроля доступа первого устройства к сети. Распространенные примеры клиентов контроля доступа включают в себя вышеупомянутый USIM, Модули идентификации абонентов CDMA (CSIM), Модуль идентификации мультимедийных IP-услуг (ISIM), Модули идентификации абонентов (SIM), Сменные модули идентификации пользователей (RUIM) и т.п.

Прежние подходы на основе SIM-карт страдали от некоторого количества ограничений. Например, традиционные UICC поддерживают только один клиент контроля доступа USIM (или, в более общем смысле, "SIM"). Если пользователь желает аутентифицироваться в сотовой сети, используя другой SIM, то пользователь должен физически поменять SIM-карту в устройстве на другую SIM-карту. Некоторые устройства спроектированы для размещения одновременно двух SIM-карт (телефоны Dual-SIM); однако такие телефоны Dual-SIM не снимают основных физических ограничений SIM-карт. Например, информацию, сохраненную на одной SIM-карте, нельзя свободно объединить с информацией, сохраненной на другой SIM-карте. Существующие устройства Dual-SIM не могут обращаться одновременно к содержимому обеих SIM-карт.

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

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

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Настоящее раскрытие изобретения предусматривает, среди прочего, крупномасштабное распространение электронных клиентов контроля доступа.

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

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

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

Также раскрывается беспроводная система.

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг. 1 - логическая блок-схема одной типовой электронной Универсальной карты с интегральной схемой (eUICC), полезной в сочетании с различными особенностями настоящего раскрытия изобретения.

Фиг. 2 - логическая блок-схема одной типовой структуры каталогов электронного Модуля идентификации абонента (eSIM), полезной в сочетании с различными особенностями настоящего раскрытия изобретения.

Фиг. 3 - логическая блок-схема, представляющая один типовой конечный автомат для Специальных файлов Модуля идентификации абонента (SIM) (SDF), полезный в сочетании с различными особенностями настоящего раскрытия изобретения.

Фиг. 4 - логическая блок-схема, представляющая один типовой конечный автомат для работы eSIM, полезный в сочетании с различными особенностями настоящего раскрытия изобретения.

Фиг. 5 - графическое представление одной типовой сети брокеров eSIM, полезной с различными вариантами осуществления настоящего раскрытия изобретения.

Фиг. 6 - логическая блок-схема одного типового многоуровневого протокола безопасности, полезного с различными вариантами осуществления настоящего раскрытия изобретения.

Фиг. 7 - графическое представление одной типовой структуры данных, содержащей три (3) части, полезной в сочетании с различными особенностями настоящего раскрытия изобретения.

Фиг. 8 - графическое представление одной типовой иерархии сертификатов OEM, полезной в сочетании с различными особенностями настоящего раскрытия изобретения.

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

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

Фиг. 11 - логическая блок-схема, иллюстрирующая одну типовую логическую последовательность для доставки комплекта eSIM на устройство.

Фиг. 12 - логическое представление устройства с электронной Универсальной картой с интегральной схемой (eUICC).

Фиг. 13 - логическое представление устройства хранения электронного Модуля идентификации абонента (eSIM).

Фиг. 14 - логическая блок-схема, иллюстрирующая одно типовое пользовательское устройство.

Фиг. 15 - логическая блок-схема, иллюстрирующая один вариант осуществления способа для крупномасштабного распространения электронных клиентов контроля доступа.

Авторское право на все чертежи принадлежит Apple Inc. © 2012-2013. Все права защищены.

ПОДРОБНОЕ ОПИСАНИЕ

Теперь приводится ссылка на чертежи, на которых одинаковые цифры ссылаются на одинаковые части по всем чертежам.

Описание типовых вариантов осуществления

Теперь подробно описываются типовые варианты осуществления и особенности настоящего раскрытия изобретения. Хотя эти варианты осуществления и особенности обсуждаются главным образом применительно к Модулям идентификации абонентов (SIM) в сотовой сети GSM, GPRS/EDGE или UMTS, средними специалистами будет выявлено, что настоящее раскрытие изобретения этим не ограничивается. Фактически, различные признаки раскрытия изобретения полезны в любой сети (будь то беспроводная сотовая или иная), которая может извлечь пользу из хранения и распространения устройствам клиентов контроля доступа.

При использовании в данном документе термины "клиент" и "UE" включают в себя, но не ограничиваются, сотовые телефоны с возможностью беспроводной связи, смартфоны (например, iPhone™), персональные компьютеры (ПК) с возможностью беспроводной связи, мобильные устройства, например наладонные компьютеры, PDA, персональные устройства мультимедиа (PMD), беспроводные планшеты (например, iPad™), так называемые "фаблеты" или любые сочетания вышеупомянутого.

При использовании в дальнейшем термины "Модуль идентификации абонента (SIM)", "электронный SIM (eSIM)", "профиль" и "клиент контроля доступа" в целом относятся к логической сущности, воплощенной либо в аппаратных средствах, либо в программном обеспечении, подходящей для контроля доступа первого устройства к сети. Распространенные примеры клиентов контроля доступа включают в себя вышеупомянутый USIM, Модули идентификации абонентов CDMA (CSIM), Модуль идентификации мультимедийных IP-услуг (ISM), Модули идентификации абонентов (SIM), Сменные модули идентификации пользователей (RUIM) и т.п. или любые сочетания вышеупомянутого.

Также станет очевидным, что хотя в этом документе используется термин "модуль идентификации абонента" (например, eSIM), этот термин никоим образом непременно не связывается или не требует либо (i) использования непосредственно абонентом (то есть различные признаки раскрытия изобретения могут быть применены на практике абонентом или не являющимся таковым); (ii) идентичности одного человека (то есть различные признаки раскрытия изобретения могут быть применены на практике от лица группы людей, например семьи, или неосязаемого либо вымышленного субъекта, например предприятия); либо (iii) какого-либо вещественного "модульного" оборудования или аппаратных средств.

Работа типовых eUICC и eSIM

Различные признаки и функции настоящего раскрытия изобретения теперь обсуждаются по отношению к одной типовой реализации. Применительно к типовому варианту осуществления настоящего раскрытия изобретения, вместо использования физической UICC, как в известном уровне техники, UICC эмулируется в виде виртуального или электронного объекта, например программного приложения, в дальнейшем называемого Электронной универсальной картой с интегральной схемой (eUICC), который заключен в некий защищенный элемент (например, защищенный микропроцессор или запоминающее устройство) в UE. eUICC допускает хранение и управление несколькими элементами SIM, в дальнейшем называемыми Электронными модулями идентификации абонентов (eSIM). Каждый eSIM является программной эмуляцией типичного USIM и содержит аналогичное программирование и ассоциированные с ним пользовательские данные. eUICC выбирает eSIM на основе ICC-ID у eSIM. Как только eUICC выбирает нужный eSIM (нужные eSIM), UE может инициировать процедуру аутентификации, чтобы получить услуги беспроводной сети от соответствующего оператора сети у eSIM.

Архитектура программного обеспечения eUICC

Ссылаясь теперь на фиг. 1, показана одна типовая электронная Универсальная карта с интегральной схемой (eUICC), полезная в сочетании с настоящим раскрытием изобретения. Примеры типовой eUICC описываются в находящейся в процессе одновременного рассмотрения заявке на патент США того же заявителя №13/093722, поданной 25 апреля 2011 г. и озаглавленной "APPARATUS AND METHODS FOR STORING ELECTRONIC ACCESS CLIENTS", полностью включенной ранее в этот документ путем ссылки, хотя будет понятно, что в соответствии с настоящим раскрытием изобретения может использоваться другая.

Фиг. 1 иллюстрирует одну типовую архитектуру eUICC на платформе Java Card™. Другие примеры операционных систем (ОС) для использования в приложениях смарт-карт включают в себя (без ограничения) MULTOS и ОС собственной разработки, при этом Java Card является всего лишь пояснительной. ОС предоставляет интерфейс между прикладным программным обеспечением и аппаратными средствами. Как правило, ОС включает в себя службы и функциональные возможности, сконфигурированные для: ввода-вывода (I/O), оперативного запоминающего устройства (RAM), постоянного запоминающего устройства (ROM), энергонезависимого (NV) запоминающего устройства (EEPROM, флэш-память) и т.п. ОС также может предоставлять криптографические службы, используемые более высокими уровнями, управление памятью и файлами и протоколы связи.

Типовая реализация Java состоит из трех частей: Виртуальная машина Java Card (JCVM) (интерпретатор байт-кода); среда исполнения Java Card (JCRE) (которая управляет ресурсами карты, исполнением апплета и другими функциями времени исполнения); и Интерфейсы прикладного программирования Java (API) (набор настроенных классов для программирования приложений смарт-карт).

JCVM имеет компонент на карте (интерпретатор байт-кода) и ответную часть вне карты (преобразователь). Некоторые задачи компиляции могут выполняться преобразователем из-за ограничений ресурсов карты. Сначала компилятор Java создает файлы классов из исходного кода. Преобразователь предварительно обрабатывает файлы классов и создает файл CAP. Преобразователь проверяет, что образы загрузки java-классов правильно оформлены, проверяет нарушения подмножества языка Java Card, а также выполняет некоторые другие задачи. Файл CAP содержит исполняемое двоичное представление классов в пакете Java. Преобразователь также формирует файлы экспорта, которые содержат открытую информацию API. В карту загружается только файл CAP. Другим широко применяемым форматом является IJC, который можно преобразовать из файлов CAP. Файлы IJC могут быть немного меньше по размеру в сравнении с файлами CAP.

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

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

В одном типовом варианте осуществления eUICC является несъемным компонентом устройства. Во время работы eUICC исполняет защищенную ОС начальной загрузки. ОС начальной загрузки убеждается, что eUICC защищена, и управляет исполнением в ней протоколов безопасности. Примеры защищенной ОС начальной загрузки описываются в находящейся в процессе одновременного рассмотрения заявке на патент США того же заявителя №13/080521, поданной 5 апреля 2011 г. и озаглавленной "METHODS AND APPARATUS FOR STORAGE AND EXECUTION OF ACCESS CONTROL CLIENTS", полностью включенной ранее в этот документ путем ссылки. Дополнительно принимается во внимание, что разные Операторы сетей мобильной связи (MNO) могут настраивать eSIM для поддержки различных степеней дифференциации обслуживания. Распространенные примеры настройки включают в себя, без ограничения, файловые структуры и/или программные приложения собственной разработки. Вследствие конфигурируемости eSIM они могут значительно отличаться по размеру.

В отличие от SIM-карт известного уровня техники eSIM-ами можно свободно обмениваться между устройствами в соответствии с защищенной транзакцией. Абонентам не нужна "физическая карта" для перемещения SIM между устройствами; однако фактическая транзакция eSIM должна быть надежно защищена, например, посредством определенных протоколов безопасности. В одном типовом варианте осуществления eSIM перед его доставкой шифруется для определенного получателя. В некоторых разновидностях каждый eSIM, в дополнение к зашифрованному содержимому, может включать в себя сегмент метаданных, который является нешифрованным текстом. Дополнительно может использоваться криптографическая подпись для обеспечения целостности содержимого нешифрованного текста. Этот сегмент метаданных может свободно предоставляться (даже незащищенным объектам) для содействия в незащищенном хранении и т.п.

Архитектура программного обеспечения eSIM

Ссылаясь теперь на фиг. 2, раскрывается одна типовая структура каталогов электронного Модуля идентификации абонента (eSIM), воплощенная в типовой eUICC. Как показано, структура каталогов eSIM изменена для поддержки гибкости, предложенной eSIM. Например, структура каталогов eSIM включает в себя, среди прочего: (i) EFeSimDir, который содержит список установленных eSIM; (ii) EFcsn, который содержит порядковый номер карты, который глобально и однозначно идентифицирует eUICC; (iii) DFsecurity хранит связанные с безопасностью данные и секретный ключ, соответствующий одному или нескольким сертификатам eUICC. В одной такой разновидности информация DFsecurity включает в себя: (i) DFepcf, который содержит PCF уровня платформы eUICC; (ii) EFoemcert, который содержит корневой сертификат и стандартное имя OEM (учетные данные OEM могут использоваться для особых операций, например заводского восстановления); (iii) EfeUICCcert, который является сертификатом eUICC; (iv) EFsL1cert, который является корневым сертификатом базовых серверов L1; (v) EFsL2cert, который является корневым сертификатом базовых серверов L2; и (vi) EFsL3cert, который является корневым сертификатом базовых серверов L3.

В одном типовом варианте осуществления структура каталогов дополнительно включает в себя Специальные файлы SIM (SDF), которые содержат файловые структуры, которые являются характерными для eSIM. Каждый SDF располагается непосредственно под MF. Каждый SDF имеет атрибут имени и SID (ID eSIM), например Идентификатор карты с интегральной схемой (ICCID). Как показано, каждый SDF дополнительно содержит DFprofile и DFcode. Кроме того, в одной разновидности все EF, связанные с PCF профиля, хранятся под DFppcf, который хранится под DFprofile.

В одном типовом варианте осуществления информация DFprofile включает в себя: (i) EFname, который является описанием eSIM (например, имя и версия eSIM); (ii) EFtype, который описывает тип eSIM (например, обычный, начальной загрузки и тестовый). Программные приложения могут использовать эту информацию, например, для отображения пиктограммы, когда используется eSIM начальной загрузки; (iii) EFsys_ver, который является минимальным номером версии программного обеспечения eUICC, необходимым для поддержки eSIM; (iv) EFnv_min, который указывает минимальный объем энергонезависимой памяти, необходимый для eSIM; (v) EFram_min, который указывает минимальный объем необходимой энергозависимой памяти; (vi) EFnv_rsvd, который указывает объем энергонезависимой памяти, зарезервированный для беспроводных транзакций (OTA); и (vii) EFram_rsvd, который указывает объем энергозависимой памяти, зарезервированный для OTA.

В одном типовом варианте осуществления информация DFcode содержит набор ключей для каждого eSIM. Эти значения в большинстве случаев нельзя считать из eUICC. Одним исключительным вариантом использования является операция экспорта, которая криптографически "упаковывает" и экспортирует весь eSIM. Поскольку шифруется весь eSIM, значения ключей остаются защищенными. В одном типовом варианте осуществления информация DFcode содержит: (i) ExEFGPinx/gPukx, который содержит глобальный PIN (индивидуальный идентификационный номер) и PUK (ключ разблокировки PIN); (ii) EFuPin/uPuk содержит универсальный PIN и PUK; (iii) EFadminx содержит коды администратора и (iv) EFotax, который содержит коды OTA. В некоторых разновидностях также может присутствовать ADFusim, который содержит дополнительные элементы, например: (i) EFk, который хранит K, 128-разрядный совместно используемый ключ аутентификации; (ii) EFopc, который хранит OPc, который выводится из ключа абонента и поля OP конфигурации операторского алгоритма (некоторые разновидности могут хранить OP вместо OPc); (iii) EFauthpar, который задает длину RES; (iv) EFalgid, который задает алгоритм аутентификации в сети (например, Milenage); (v) EFsan, который хранит SQN; и (vi) EFlpinx/lpukx, который хранит PIN и PUK-код для локального PIN.

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

Ссылаясь теперь на фиг. 3, иллюстрируется один типовой конечный автомат для работы SDF. Как показано, конечный автомат SDF содержит следующие состояния: СОЗДАНИЕ, ИНИЦИАЛИЗАЦИЯ, РАБОЧЕЕ (АКТИВИРОВАНО), РАБОЧЕЕ (ДЕАКТИВИРОВАНО) и ЗАВЕРШЕНИЕ.

Когда eSIM устанавливается первый раз, создается SDF (СОЗДАНИЕ), а затем инициализируется (ИНИЦИАЛИЗАЦИЯ) данными файловой структуры, включенными в eSIM. Как только eSIM установлен, SDF переходит в состояние ДЕАКТИВИРОВАНО. Во время деактивированного состояния не доступны никакие файлы. Как только eSIM выбирается, SDF переходит из состояния ДЕАКТИВИРОВАНО в состояние АКТИВИРОВАНО; состояние АКТИВИРОВАНО дает возможность доступа к файлам в SDF. Когда выбор eSIM отменяется (либо неявно, либо явно), SDF переходит из состояния АКТИВИРОВАНО обратно в состояние ДЕАКТИВИРОВАНО.

Ссылаясь теперь на фиг. 4, иллюстрируется один типовой конечный автомат для работы eSIM. Как показано, конечный автомат eSIM содержит следующие состояния: УСТАНОВЛЕНО, ВЫБРАНО, ЗАБЛОКИРОВАНО, ДЕАКТИВИРОВАНО, ЭКСПОРТИРОВАНО и УДАЛЕНО.

Во время установки eSIM (УСТАНОВЛЕНО) в реестре eUICC создается запись для eSIM; запись указывает один или несколько ассоциированных SDF и приложений. Во время состояния УСТАНОВЛЕНО SDF устанавливаются в состояние ДЕАКТИВИРОВАНО, а приложения устанавливаются в состояние УСТАНОВЛЕНО.

Как только eSIM выбирается, eSIM переходит в состояние ВЫБРАНО. Во время выбранного состояния SDF переходят в состояние АКТИВИРОВАНО, а приложения переводятся в состояние ВЫБРАНО. Если выбор eSIM отменяется, то eSIM переходит обратно в состояние УСТАНОВЛЕНО.

В определенных обстоятельствах eSIM может входить в состояние ЗАБЛОКИРОВАНО. Например, если PCF eUICC меняется так, что установленный eSIM уже нельзя использовать, то eSIM перейдет в состояние ЗАБЛОКИРОВАНО. В состоянии ЗАБЛОКИРОВАНО SDF устанавливаются в состояние ДЕАКТИВИРОВАНО, а приложения устанавливаются в состояние ЗАБЛОКИРОВАНО. Различные другие состояния включают в себя состояние ЭКСПОРТИРОВАНО (то есть там, где eSIM экспортируется, и его уже нельзя выбрать) и состояние УДАЛЕНО (то есть там, где eSIM удаляется).

Алгоритмы аутентификации в сети

Алгоритмы аутентификации в сети (NAA), как правило, обязательны для работы с Операторами сетей мобильной связи (MNO). Хотя существуют разные реализации NAA, функциональные возможности отличаются незначительно. В некоторых вариантах осуществления eUICC может включать в себя общие пакеты для NAA. Во время установки eSIM может создаваться экземпляр каждого приложения NAA для каждого eSIM из заранее загруженных пакетов, чтобы уменьшить общее время загрузки eSIM и ненужное потребление памяти на eUICC.

Распространенные примеры NAA включают в себя, без ограничения: Milenage, COMP128 V1, COMP128 V2, COMP128 V3 и COMP128 V4 и некоторые алгоритмы собственной разработки. Существует большое количество алгоритмов собственной разработки, которые по-прежнему используются (из-за известных атак на COMPI28 VI). В одном варианте осуществления аутентификация в сети основывается на общеизвестном протоколе соглашения об аутентификации и ключах (AKA).

В маловероятном случае, что NAA скомпрометирован, заменяющие схемы NAA могут потребовать обновления программного обеспечения. В таком случае eSIM можно исправить с помощью заменяющего алгоритма, например посредством защищенного обновления программного обеспечения. После этого MNO может разрешить заменяющий алгоритм посредством существующего механизма OTA.

Типовая сеть брокеров eSIM

Фиг. 5 показывает высокоуровневое представление одной типовой сети брокеров eSIM, полезной с различными вариантами осуществления настоящего раскрытия изобретения. В одном типовом варианте осуществления сеть брокеров содержит распределенную сеть брокеров и производителей, так что устройство может обслуживаться несколькими брокерами и брокер может заказывать eSIM у нескольких производителей eSIM. В некоторых вариантах осуществления могут существовать политики профилей eUICC и/или eSIM, которые ограничивают группу брокеров, с которой может взаимодействовать устройство, определенными операциями eSIM. Например, MNO может требовать, чтобы устройства, которые субсидируются MNO, взаимодействовали только с брокерами, которыми владеет MNO.

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

Средние специалисты в связанных с сетями областях признают, что возникает несколько практических проблем во время работы сетей крупномасштабного распространения, например, которая представлена на фиг. 5. В частности, сети крупномасштабного распространения обязаны быть масштабируемыми, чтобы справляться с большими всплесками обеспечивающего трафика (например, могут возникать в так называемый "день запуска" данного мобильного пользовательского устройства). Одна предложенная схема для уменьшения общего сетевого трафика влечет за собой предварительную персонализацию eSIM (где это возможно) перед днем запуска. Например, так называемые модули "внутри SIM" назначаются eSIM уже при отправке; этот заранее назначенный eSIM можно предварительно персонализировать для модуля, например, путем шифрования соответствующего профиля eSIM ключом, специфичным для eUICC модуля.

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

В идеале брокерская сеть может гибко приспосабливаться к различным бизнес-моделям. В частности, по различным правовым и антимонопольным причинам различные компоненты вышеупомянутой сети брокеров могут управляться разными участниками. Соответственно, нужно тщательно наблюдать и оценивать аспекты безопасности трафика eSIM. Каждый eSIM содержит ценную информацию о пользователе и MNO. Например, eSIM может включать в себя совместно используемый ключ аутентификации (K для USIM и Ki для SIM), который при компрометации может использоваться для клонирования SIM. Аналогичным образом eSIM также могут содержать приложения, которые могут иметь уязвимые пользовательские данные, например информацию о банковском счете.

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

В конечном счете работа сети должна предусматривать "положительное" восприятие пользователем. Чрезмерное время отклика, ненадежная работа, чрезмерные сбои программного обеспечения и т.п. могут значительно испортить общее восприятие пользователем.

Типовой протокол безопасности

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

В одном типовом варианте осуществления раскрывается трехуровневая (3) система. Как проиллюстрировано на фиг. 6, программный протокол безопасности содержит Уровень 1 (L1), Уровень 2 (L2) и Уровень 3 (L3). Безопасность L1 выполняет шифрование и дешифрование данных eSIM. Операции L1 ограничиваются защищенными средами исполнения (например, eUICC или Аппаратный модуль безопасности (HSM)). В L1 данные eSIM могут храниться в виде нешифрованного текста (то есть незашифрованными) в пределах логической границы L1; за пределами границы L1 данные eSIM всегда надежно зашифрованы. Безопасность L2 обеспечивает, что eSIM нельзя скопировать. Граница L2 обеспечивает, что существует одна и только одна копия eSIM. В пределах границы L2 могут существовать несколько копий. Кроме того, безопасность L2 может дополнительно внедрять некую задачу в зашифрованную полезную нагрузку eSIM; получатель eSIM сравнит принятую задачу с задачей, сохраненной перед установкой eSIM, чтобы убедиться, что его eSIM не устарел (то есть является действующим уникальным eSIM). Безопасность L3 отвечает за установление доверия, принадлежности и проверки пользователя. Для каждого eSIM eUICC может хранить информацию для указания принадлежности, ассоциированной с eSIM.

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

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

Однако один недостаток вышеупомянутой схемы состоит в том, что фиксированное количество задач можно легко скомпрометировать с помощью атаки типа "отказ от обслуживания" (DoS). При атаке типа DOS eUICC постоянно побуждают формировать задачи, пока не будут исчерпаны все ее ресурсы для задач. Соответственно, в одной такой разновидности eUICC дополнительно выполняет подтверждение сеанса, чтобы аутентифицировать сервер/агента профиля перед обработкой запросов, которые побудили бы eUICC создавать задачи. Более того, в маловероятном случае, когда исчерпаны ресурсы и eUICC не способна создавать новые задачи, eUICC может хранить отдельный набор зарезервированных задач, специально предназначенный для высвобождения другого набора задач. В некоторых случаях eUICC может дополнительно включать в себя учетные данные изготовителя комплектного оборудования (OEM), которые OEM может использовать для дополнительного управления процессом задач.

Ссылаясь теперь на фиг. 7, иллюстрируется одна типовая структура данных для eSIM. Как показано, типовая структура данных содержит три (3) части, по одной для каждого из уровней L1, L2 и L3 безопасности. С помощью разведения компонентов безопасности по отдельным уровням общую работу сети можно распределить по нескольким объектам в соответствии с широким спектром опций. Например, различные сетевые объекты могут выполнять только один или два из уровней безопасности (например, поставщик eSIM может обрабатывать только L2 и т.п.); эта гибкость легко и успешно вмещает в себя практически любую коммерческую схему.

Как показано на фиг. 7, поскольку асимметричное шифрование (то есть там, где каждый объект имеет отдельный и уникальный ключ) гораздо медленнее симметричной операции (где объекты совместно используют ключ), каждый компонент 702 профиля eSIM шифруется симметричным ключом, а симметричный ключ шифруется открытым ключом L1 предназначенного получателя eSIM. eSIM может дополнительно включать в себя сегмент нешифрованного текста для метаданных (например, текстовую строку ICCID). Зашифрованный симметричный ключ, метаданные и зашифрованное содержимое eSIM хешируются и подписываются открытым ключом "жертвующего" объекта L1. Ассоциированный сертификат L1 прикрепляется, например, в конце для проверки.

Компонент 704 дескриптора комплекта из фиг. 7 содержит информацию L2 для eSIM. Он имеет сегмент нешифрованного текста, включающий в себя Глобально уникальный Идентификатор (GUID), задачу для предназначенного получателя eSIM, уникальный ID получателя eSIM, URL для извлечения профиля и URL для помещения результата установки. Дескриптор комплекта также включает в себя сегмент нешифрованного текста из массива элементов, которые состоят из: ICCID для каждого профиля и хешированной части профиля (сегмент метаданных и зашифрованное содержимое eSIM). В одном варианте осуществления хеш не включает в себя симметричный ключ, так что дескриптор комплекта можно создать, не ожидая формирования фактического профиля. Для операции на стороне устройства дескриптор комплекта содержит только один ICCID и хеш профиля. Для группового переноса с сервера на сервер предполагается гораздо больший массив. Содержимое дескриптора комплекта хешируется и подписывается открытым ключом L2, и в конце прикрепляется ассоциированный сертификат L2.

Компонент 706 владельца L3 содержит информацию L3 для eSIM. Поле принципала идентифицирует учетную запись пользователя, ассоциированную с eSIM (например, abc@me.com), имя услуги идентифицирует поставщика услуг, у которого нужно аутентифицировать учетную запись пользователя. Хеш дескриптора комплекта включается для ассоциации структур L2 и L3 данных. Данные могут храниться в виде нешифрованного текста, хешированного и подписанного открытым ключом L3. В конце прикрепляется сертификат L3.

При использовании в данном документе существует три (3) типа сертификатов: сертификаты eUICC, сертификаты базовых серверов и сертификаты OEM. В одном варианте осуществления доверенное третье лицо выдает сертификаты для сертифицированных eUICC. Каждая eUICC содержит секретный ключ и ассоциированный сертификат, выданный этим субъектом или подчиненным центром ключей этого субъекта. В некоторых вариантах осуществления одно доверенное третье лицо может выдавать сертификаты для сертифицированных базовых серверов L1, L2 и L3; или наоборот, отдельные сторонние субъекты могут выдавать сертификаты для базовых серверов L1, L2 или L3. Там, где существует несколько третьих лиц, eUICC имеет заранее загруженный (или может предоставляться OTA от доверенного субъекта) корневой Центр сертификации (CA) третьих лиц и может проверять сообщения, принятые от базовых серверов, на основе подходящего CA.

Ссылаясь теперь на фиг. 8, иллюстрируется одна типовая иерархия сертификатов OEM. Корневой центр сертификации (CA) имеет набор промежуточных CA, которые выполняют подмножество задач (например, выдачу сертификатов iOS или сопоставимых устройств). Как показано, CA eUICC отвечает за характерные для eSIM операции. CA eUICC может выдавать сертификаты для набора серверов; как показано, сертификаты включают в себя, например, серверы заводского восстановления для обслуживания eUICC и серверы активации для подписывающей PCF eUICC. Корневой CA вместе со стандартным именем CA eUICC используются eUICC клиента для проверки подписанных сообщений OEM.

В соответствии с вышеупомянутым, в одном типовом варианте осуществления каждая eUICC клиента хранит следующие связанные с безопасностью данные: (i) сертификат eUICC, который используется для операций eUICC L1, L2 и L3 (каждая eUICC хранит сертификат, который используется для связанных с безопасностью операций L1, L2 и L3); (ii) секретный ключ eUICC, который ассоциируется с сертификатом eUICC; (iii) учетные данные OEM, которые включают в себя корневой сертификат OEM и стандартное имя CA eUICC OEM; (iv) и корневые сертификаты третьих лиц, которые могут сертифицировать базовые серверы. В некоторых разновидностях сертификаты на eUICC может понадобиться заменить, если подписывающий CA скомпрометирован; например, если CA eUICC или CA сервера скомпрометирован (например, скомпрометирован/потерян секретный ключ), то ниже описываются две (2) процедуры аннулирования.

В соответствии с первой типовой процедурой аннулирования, если скомпрометирован подписывающий CA, который выдает сертификаты eUICC, то следует заменить сертификат eUICC, сохраненный в затронутых eUICC. В частности, когда создавался начальный запрос сертификата для eUICC, был сохранен Запрос подписания сертификата (CSR). Если подписывающий CA скомпрометирован, то можно запросить новый сертификат для eUICC, используя начальный CSR. Храня один и тот же CSR, eUICC может использовать одинаковый секретный ключ, и будет выдан новый сертификат, содержащий одинаковый открытый ключ eUICC. OEM может подписать новый сертификат секретным ключом OEM. Когда eUICC отправляет запросы брокеру сервера, брокер может проверить список аннулирования плохих CA eUICC и отклонить запрос с помощью конкретной ошибки для указания, что сертификат нужно заменить. AP может извлечь новый сертификат eUICC посредством существующих служб OEM и отправить новый сертификат к eUICC (в этом сценарии AP не должен быть доверенным).

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

К сожалению, аннулирование сертификатов сервера на eUICC может быть затруднительным из-за различных ограничений ресурсов eUICC; то есть обработка большого списка аннулирования может быть неприемлемой для eUICC. Чтобы избежать ведения списков аннулирования, во второй схеме аннулирования каждый сертификат сервера дополнительно ассоциируется с периодом. Если CA скомпрометирован, то корневой CA повторно выдает сертификаты для всех законных субъектов и увеличивает период у каждого нового сертификата. Поскольку количество сертификатов сервера не будет большим, повторная выдача сертификатов может проводиться в существующих системах. На eUICC клиента eUICC сохраняет предполагаемый период сертификатов сервера L1, L2 и L3 в энергонезависимой памяти. Когда принятый сертификат содержит больший период, eUICC должна обновить соответствующий период NV и отклонить любые будущие сертификаты с меньшим периодом; то есть eUICC будет отклонять незаконные серверы, которые не подписаны, поскольку CA был скомпрометирован. В некоторых разновидностях сервер также может вести черный список eUICC для скомпрометированных eUICC. Сервером отклоняются запросы от eUICC в черном списке в одном варианте осуществления.

Функции управления политиками

В контексте вышеупомянутого решения по безопасности существует два (2) уровня Функций управления политиками (PCF): (i) уровень платформы eUICC и (ii) уровень профиля. В одном типовом варианте осуществления PCF eUICC может обновляться только с помощью OEM, тогда как PCF профиля управляется с помощью MNO и является частью eSIM. В одной такой разновидности, когда eSIM экспортируется и/или импортируется, PCF профиля включается как пакет экспорта/импорта.

Ссылаясь теперь на PCF eUICC, PCF eUICC может включать в себя: (i) политику блокировки SIM, которая задает типы eSIM, которые может активировать eUICC; (ii) секретный код, который может использоваться для авторизации удаления всех eSIM на eUICC; (iii) список стандартных имен сервера (L1, L2 и L3), которые задают кластер базовых серверов, с которыми может взаимодействовать eUICC (например, на основе коммерческих соображений или способов) (то есть включающий перечень); (iv) список стандартных имен сервера (L1, L2 и L3), которые задают кластер базовых серверов, с которыми eUICC может не взаимодействовать (то есть исключающий перечень).

Аналогичным образом, PCF профиля может включать в себя: (i) список стандартных имен серверов (L1, L2 и L3), которые задают кластер хранилищ, в которые eUICC может экспортировать eSIM (включающий); (ii) список стандартных имен серверов (L1, L2 и L3), которые задают кластер хранилищ, в которые eUICC может не экспортировать eSIM (исключающий); (iii) URL уведомления и типы операций, которые задают URL, по которым отправляются уведомления по завершении заданной операции eSIM; (iv) параметры автоматического истечения срока, где AP может удалять eSIM, как только истек срок профиля; (v) классы базовых серверов (L1, L2 и L3), которым могут назначаться разные классы, указывающие реализованные уровни безопасности (профиль может решить взаимодействовать только с компонентами сервера выше некоторых уровней); (vi) период сертификатов сервера (L1, L2 и L3), который проверяется во время установки (например, eUICC устанавливает профили, только если период сертификатов сервера eUICC больше либо равен заданному периоду); (vii) имена служб L3, которые может использовать аутентификация L3, и/или список имен служб, которые аутентификация L3 не может использовать; (viii) минимальную версию системы eUICC (где eSIM может устанавливаться только на системы eUICC старше заданной минимальной версии); (ix) минимальный размер RAM, необходимый для eSIM (не включая операции OTA); (x) минимальный размер RAM, зарезервированный для OTA; (xi) минимальный размер энергонезависимой (NV) памяти, необходимый для eSIM (исключая пространство, зарезервированное для OTA); (xii) минимальный размер NV, зарезервированный для OTA

Примерная работа

В контексте вышеупомянутых компонентов (например, eUICC, eSIM, сеть брокеров, протокол безопасности и т.п.) раскрываются следующие типовые последовательности обмена сообщениями. На схемах последовательностей ниже представляются три субъекта: брокер, агент профиля и контейнер профилей, для представления субъектов, которые отвечают соответственно за безопасности L3, L2, L1. Однако следует принять во внимание, что они являются логическими сущностями и разные топологии сети могут относить к какой-либо категории или дополнительно различать их вышеупомянутые функции.

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

Доставка eSIM без персонализации

Фиг. 9 иллюстрирует одну типовую логическую последовательность для доставки eSIM на устройство без персонализации. Сначала устройство идентифицирует брокер сервера посредством процесса обнаружения (не показан). Как только устройство пытается взаимодействовать с брокером сервера, существует три основных операции: (i) устройство спрашивает у внутреннего интерфейса сервера о доступных опциях eSIM; (ii) устройство запрашивает, чтобы сервер персонализировал eSIM, если запрошенный eSIM не был предварительно персонализирован; и (iii) устройство загружает фактический eSIM и устанавливает его.

На первом этапе устройством используется getProfileOptions для запроса у внутреннего интерфейса сервера доступных опций eSIM. eUICC, ассоциированная с устройством, идентифицируется по его UniqueId, который может быть, например, порядковым номером карты. Брокер использует информацию продаж для определения одной или нескольких опций eSIM, доступных устройству. Для разблокированных устройств может быть очень большой набор доступных eSIM; соответственно, в некоторых вариантах осуществления отображаются распространенные опции, которые, скорее всего, выбираются пользователем (например, на основе местоположения, стоимости и т.п.). Сервер возвращает массив поставщиков профилей (MNO) и типов профилей (например, предварительно оплаченный/оплаченный по факту), который допустим для устройства.

В некоторых сценариях тип доступных пользователю eSIM может считаться конфиденциальной информацией, поэтому в некоторых разновидностях API getProfileOptions дополнительно требует от eUICC L3 устройства подписать уникальный идентификатор eUICC и включить подписанный идентификатор в API. Брокер сервера (или сервер брокера) может проверить подпись перед обработкой запроса. Это препятствует извлечению злоумышленником опций профиля пользователей путем отправки запросов с подменой. В некоторых разновидностях связь между брокером устройства и брокером сервера использует протокол безопасности (например, безопасность транспортного уровня (TLS)) для предотвращения перехвата и атак с повторением пакетов.

В одном варианте осуществления getProfileOptions содержит два маркера L3 для проверки текущей и новой принадлежности eSIM. Текущий маркер L3 может быть уникальным идентификатором или так называемым скретч-кодом от "искусственной карты". Новый маркер L3 может быть информацией, используемой для ассоциации учетной записи пользователя с eSIM, например маркер входа для учетной записи в iCloud (например, где устройство вошло в учетную запись пользователя для извлечения маркера). Оба маркера L3 подписываются eUICC L3. Брокер сервера проверяет достоверность маркеров L3 с использованием ассоциированной службы аутентификации. Например, он может взаимодействовать с сетевым сервером (например, сервером iCloud Правопреемника) или сторонней службой для проверки достоверности маркера входа.

Чтобы оптимизировать производительность и избежать двойной аутентификации, после аутентификации переданного устройством маркера брокер сервера формирует одноразовый код (OTC) и передает OTC обратно устройству. Устройство может использовать OTC в качестве доказательства, что сервер уже выполнил аутентификацию L3. Большой двоичный объект (BLOB) полных данных может включать в себя сформированный OTC, уникальный идентификатор устройства (например, порядковый номер карты (CSN)), принципала, поставщика услуг и отметку времени для указания достоверности OTC. BLOB хешируется и подписывается брокером. В одной разновидности хеширование выполняется симметричным ключом, чтобы повысить общую производительность. Если getProfileOptions возвращает массив eSIM, то пользователя приглашают сделать выбор.

На втором этапе устройство вызвало бы personalizeProfile для запроса у внутреннего интерфейса сервера персонализировать eSIM. Перед тем как устройство отправляет серверу запрос персонализации, имеет место подтверждение сеанса между агентом профиля eUICC и агентом профиля сервера для аутентификации. Брокер устройства и eUICC создают сеанс на основе опции профиля, которую выбрал пользователь, и текущего кода L3 и нового кода L3, отправленных брокером сервера. eUICC может сохранить эту информацию для заполнения запроса профиля, отправляемого впоследствии. Агент профиля eUICC формирует id сеанса, который будет возвращен агентом сервера для последующей аутентификации.

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

Если запрос является подходящим, то брокер сервера передает запрос агенту профиля. Агент профиля проверяет запрос криптографически путем проверки сертификата L2 eUICC и с использованием открытого ключа L2 eUICC для проверки подписи L2. Как только проверка проходит, агент профиля сервера создает SessionResponse, включающий в себя сегмент нешифрованного текста, содержащий: принятый идентификатор сеанса и уникальный идентификатор, подпись L2 (сформированную путем хеширования сегмента нешифрованного текста и подписания хеша с использованием секретного ключа агента профиля сервера) и сертификат агента профиля сервера.

Ответ сеанса отправляется от агента профиля сервера к брокеру сервера, который затем перенаправляет ответ сеанса к брокеру устройства. Брокер устройства передает ответ в eUICC в сообщении prepareProfileRequest. eUICC L2 проверяет SessionReponse путем проверки сертификата агента профиля сервера и подписи L2. eUICC L2 также проверяет, что идентификатор сеанса и уникальный идентификатор совпадают с информацией в eUICC. Как только проверка проходит, eUICC создает задачу для запроса принадлежности. Информация о владельце L3 может предоставляться в более позднее время, если пользователь экспортирует eSIM.

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

Доставка eSIM, предварительная персонализация

Фиг. 10 иллюстрирует одну типовую логическую последовательность для доставки eSIM на устройство с предварительной персонализацией. Аналогично схеме из фиг.9, доставка предварительно персонализированного eSIM требует трех (3) этапов.

Сначала, во время производства клиентского устройства, заводской брокер дает eUICC команду создать задачу для предварительной персонализации eSIM позднее. Однако в отличие от схемы из фиг.9 устройство еще не ассоциировано с MNO или типом eSIM; точнее, эти поля заполняются специальным значением для указания, что выбор будет сделан позже. Полное содержимое BLOB запроса профиля сохраняется для использования в персонализации позднее.

Второй этап запускается автоматически, например, с помощью уведомления об отправке, продажи устройства и т.п. L2 (агент профиля клиента) в центре распространения действует в качестве посредника для eUICC L2 клиента. Хотя BLOB запроса профиля eUICC не содержит MNO и тип eSIM, агент профиля клиента может восстановить BLOB путем замены этих полей обновленной информацией. Агент профиля клиента может создать собственную задачу и заменить задачу eUICC. Агент профиля клиента подпишет содержимое своим секретным ключом (в противном случае все L2 потребовали бы уникальных задач). BLOB будет содержать подпись L1 eUICC, eUICC по-прежнему нужно дешифровать персонализированный eSIM. Новый BLOB запроса профиля отправляется брокеру сервера с использованием существующего запроса personalizeProfile. В дальнейшем процедура не отличается от процедуры из фиг. 9.

Кроме того, дополнительно принимается во внимание, что даже если MNO хотел бы поддерживать собственную брокерскую систему, раскрытый процесс предварительной персонализации мог бы использовать такой же интерфейс. Брокер сервера вернет дескриптор комплекта клиенту и персонализирует eSIM. Агент профиля клиента создал бы новый дескриптор комплекта с задачей eUICC, который будет использоваться, когда eUICC позднее запрашивает профиль.

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

Доставка eSIM, доставка комплекта

Фиг. 11 иллюстрирует одну типовую логическую последовательность для доставки большого количества (комплекта) eSIM, например, между двумя объектами. В одном варианте осуществления брокер клиента и брокер сервера являются защищенными объектами, которые имеют защищенную связь посредством, например, Виртуальной частной сети (VPN). Поддерживается "комплектование", так что клиент может разместить заказ на большое количество eSIM.

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

Экспорт eSIM

В конечном счете, как только eSIM сохраняется на клиентское устройство, пользователь может решить экспортировать eSIM из устройства, а позднее импортировать eSIM на то же или другое устройство. Одна цель состоит в поддержке смены eSIM. Другая цель состоит в освобождении памяти eUICC для хранения дополнительных eSIM. При экспорте существует три возможных сценария: (i) экспорт в "облако", (ii) экспорт в AP (для внешнего хранения) и (iii) перенос eSIM с устройства на устройство. Аналогичным образом пользователь может импортировать из "облака", AP или другого устройства.

Во время установки eSIM информация об учетной записи пользователя ассоциируется с eSIM (если пользователь не откажется). Информация об учетной записи включает в себя достаточно информации для аутентификации L3. Например, она может включать в себя принципала (например, x2z@yahoo.com) и ассоциированного поставщика услуг для аутентификации. Если никакая информация об учетной записи не ассоциируется с eSIM, то пользователь может экспортировать eSIM с помощью других способов аутентификации. Один такой вариант осуществления включает в себя физическую кнопку, которая жестко соединена с eUICC, чтобы доказать физическое обладание устройством. В другом варианте осуществления каждый eSIM включает в себя уникальный пароль, и у пользователя должен быть пароль, чтобы доказать свою принадлежность. Использование учетных данных OEM является еще одним вариантом.

Когда пользователь экспортирует eSIM, AP извлекает из eUICC список установленных профилей; для каждого профиля eUICC также возвращает ассоциированного принципала и одноразовый номер, сформированный для противодействия повторам. Когда пользователь решает экспортировать профиль, AP использует информацию, содержащуюся на принципале, чтобы получить маркер единого входа (SSO) от поставщика услуг, где пользователя с этой целью пригласили бы ввести имя пользователя и пароль. Маркер SSO передается вместе принципалом и одноразовым номером брокеру сервера в запросе экспорта. Брокер сервера может пройти аутентификацию у поставщика услуг, используя маркер SSO, переданный устройством. Как только проходит аутентификация, алгоритм воспроизводит доставку eSIM на устройство за исключением того, что роли клиента и сервера меняются. На верхнем уровне брокер сервера инициирует сеанс с eUICC, создает BLOB запроса для экспорта. В этот запрос он включает одноразовый номер, который сформировала eUICC, для указания, что операция прошла аутентификацию L3. eUICC проверяет BLOB запроса, шифрует eSIM открытым ключом агента сервера, создает дескриптор комплекта и информацию о владельце L3 для eSIM. eSIM вместе с информацией L3 и L2 можно отправить на сервер.

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

В некоторых вариантах осуществления экспорт также может инициироваться с некоторого веб-портала. Если пользователь теряет свое устройство, то он может использовать веб-портал для экспорта eSIM со своего устройства. В этом случае веб-портал взаимодействовал бы с устройством, чтобы инициировать операцию экспорта. Алгоритм при этом аналогичный за исключением того, что пользователь использовал бы веб-портал вместо AP, чтобы получить маркер SSO для проверки принадлежности.

Устройство

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

Устройство eUICC

Фиг. 12 иллюстрирует один типовой вариант осуществления устройства 1200 eUICC в соответствии с настоящим раскрытием изобретения. Устройство eUICC может быть выполнено в виде автономного объекта или может объединяться с другими сетевыми объектами, например серверами. Как показано, устройство 1200 eUICC в целом включает в себя сетевой интерфейс 1202 для сопряжения с сетью связи, процессор 1204 и одно или несколько устройств 1206 хранения. Сетевой интерфейс показан подключенным к инфраструктуре MNO, чтобы предоставлять доступ к другим устройствам eUICC и прямой или косвенный доступ к одному или нескольким мобильным устройствам, хотя можно подставить и другие конфигурации и функциональные возможности.

В одной конфигурации устройство eUICC допускает: (i) установление связи с другой eUICC (либо устройством eUICC, либо клиентским устройством), (ii) надежное хранение eSIM, (iii) извлечение надежно сохраненного eSIM, (iv) шифрование eSIM для доставки в другую конкретную eUICC и (v) отправку нескольких eSIM в хранилище eSIM/из него.

Хранилище eSIM

Фиг. 13 иллюстрирует один типовой вариант осуществления хранилища 1300 eSIM в соответствии с настоящим раскрытием изобретения. Хранилище 1300 eSIM может быть реализовано в виде автономного объекта или может объединяться с другими сетевыми объектами (например, устройством 1200 eUICC и т.п.). Как показано, хранилище 1300 eSIM в целом включает в себя сетевой интерфейс 1302 для сопряжения с сетью связи, процессор 1304 и устройство 1306 хранения.

В проиллюстрированном варианте осуществления из фиг.1300 хранилище 304 eSIM допускает: (i) управление запасами eSIM (например, посредством ассоциированных метаданных), (ii) ответ на запросы зашифрованных eSIM (например, от других хранилищ eSIM и/или устройств 1200 eUICC), (iii) управление запросами eSIM от абонентов.

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

Пользовательское устройство

Ссылаясь теперь на фиг. 14, иллюстрируется типовое пользовательское устройство 1400 в соответствии с различными особенностями настоящего раскрытия изобретения.

Типовое устройство UE из фиг. 14 является беспроводным устройством с процессорной подсистемой 1402, например цифровым процессором сигналов, микропроцессором, программируемой пользователем вентильной матрицей или множеством компонентов обработки, смонтированных на одной или нескольких подложках. Подсистема обработки также может содержать внутреннюю кеш-память. Подсистема обработки связана с подсистемой 1404 памяти, включающей в себя память, которая может содержать, например, компоненты SRAM, флэш-памяти и/или SDRAM. Подсистема памяти может реализовать одно или несколько аппаратных средств типа DMA, чтобы упростить обращения к данным, которые хорошо известны в данной области техники. Подсистема памяти содержит исполняемые компьютером команды, которые исполняются процессорной подсистемой.

В одном типовом варианте осуществления устройство включает в себя один или несколько беспроводных интерфейсов 1406, приспособленных для подключения к одной или нескольким беспроводным сетям. Несколько беспроводных интерфейсов могут поддерживать разные технологии радиосвязи, например GSM, CDMA, UMTS, LTE/LTE-A, WiMAX, WLAN, Bluetooth и т.п., путем реализации подходящих подсистем из антенны и модема хорошо известного в области беспроводной связи типа.

Подсистема 1408 интерфейса пользователя включает в себя любое количество общеизвестных устройств ввода-вывода (I/O), включая, без ограничения: клавишную панель, сенсорный экран (например, мультисенсорный интерфейс), дисплей на LCD, заднюю подсветку, динамик и/или микрофон. Однако признается, что в некоторых применениях один или несколько этих компонентов можно исключить. Например, варианты осуществления клиента в виде платы PCMCIA могут не иметь интерфейса пользователя (так как они могли бы пользоваться интерфейсом пользователя у хост-устройства, с которым они физически и/или электрически соединены).

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

Защищенный элемент дополнительно приспособлен для обеспечения возможности переноса eSIM на мобильное устройство и/или с мобильного устройства. В одной реализации мобильное устройство предоставляет основанное на GUI подтверждение приема, чтобы инициировать перенос eSIM.

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

Способы

Теперь подробнее описываются различные способы, полезные в сочетании с вышеописанными способами.

Фиг. 15 иллюстрирует один вариант осуществления способа для крупномасштабного распространения электронных клиентов контроля доступа.

На этапе 1502 первое устройство устанавливает принадлежность одного или нескольких электронных клиентов контроля доступа.

На этапе 1504 первое устройство определяет, не копировались ли ранее один или несколько электронных клиентов контроля доступа.

На этапе 1506 первое устройство шифрует один или несколько электронных клиентов контроля доступа для переноса на второе устройство.

На этапе 1508 первое устройство и второе устройство обменивают или переносят один или несколько зашифрованных электронных клиентов контроля доступа.

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

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

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