Способ аутентификации приложений
Изобретение относится к области мобильной связи. Технический результат заключается в предотвращении возможности нецелевого использования приложений в мобильных устройствах. Сущность изобретения заключается в том, что принимают данные, включающие в себя по меньшей мере идентификатор (IMEISV) оборудования (СВ) и идентификатор (IMSI) модуля (SIM) защиты, посредством сервера (CSE) управления через сеть (NET); анализируют и проверяют указанные данные посредством сервера (CSE) управления; генерируют криптограмму (CRY), содержащую контрольную сумму (FIN1) приложения (АРР), идентификационные данные оборудования (СВ) и модуля (SIM) защиты и команды (INS RES), предназначенные для указанного модуля; передают указанную криптограмму (CRY) по сети (NET) и через оборудование (СВ) в модуль (SIM) защиты; проверяют приложение (АРР) путем сравнения контрольной суммы (FIN1), извлеченной из полученной криптограммы (СРУ), с контрольной суммой (FIN2), определенной модулем защиты, причем в процессе инициализации и/или активации приложения (АРР) модуль (SIM) защиты выполняет команды (INS-RES), извлеченные из криптограммы (CRY), и соответственно предоставляет или блокирует доступ к определенным ресурсам (RES) указанного модуля защиты (SIM) в зависимости от результата ранее выполненной проверки в отношении этого приложения (АРР). 2 н. и 16 з.п. ф-лы, 4 ил.
Область изобретения
Настоящее изобретение относится к области сетей мобильной связи, также называемых сетями сотовой связи. В частности, настоящее изобретение относится к управлению безопасностью приложений посредством модуля защиты, соединенного с мобильным оборудованием мобильной телефонии.
Уровень техники
Модуль защиты мобильного или переносного телефона известен под названием "SIM-карта" (Subscriber Identity Module, модуль идентификации абонента) и представляет собой основной элемент защиты таких телефонов. При производстве и/или на стадии персонализации телефонный оператор вводит номер, называемый IMSI (International Mobile Subscriber Identification, международный идентификатор мобильного абонента), который служит для однозначной и безопасной идентификации каждого абонента, желающего соединиться с сетью мобильной связи. Каждый мобильный телефон, далее называемый "мобильное оборудование", физически идентифицируется номером, хранящимся в энергонезависимой памяти мобильного оборудования. Этот номер, называемый IМЕI (International Mobile Equipment Identifier, международный идентификатор мобильного оборудования) содержит идентификатор типа мобильного оборудования и серийный номер, предназначенный для однозначной идентификации данного мобильного оборудования в сети типа GSM (Global System for Mobile Communications, глобальная система мобильной связи), GPRS (General Packet Radio System, система пакетной радиосвязи общего пользования) или UMTS (Universal Mobile Telecommunications System, универсальная мобильная система передачи данных). Кроме того, мобильное оборудование характеризуется версией программного обеспечения - SVN (Software Version Number, номер версии программного обеспечения), которая обозначает степень актуальности основного программного обеспечения, установленного на мобильном оборудовании. Комбинация идентификаторов типа и серийного номера мобильного оборудования с версией программного обеспечения (SVN) представляет собой новый идентификатор, называемый IMEISV (International Mobile Equipment Identifier and Software Version Number, международный идентификатор мобильного оборудования и номер версии программного обеспечения). Такой же принцип идентификации применяется в сетях WLAN (Wireless LAN, беспроводная локальная сеть) и в области двунаправленного кабельного телевидения. Физический идентификатор может представлять собой МАС-адрес (Media Access Control, управление доступом к среде), который соответствует уникальному адресу, идентифицирующему физическую конфигурацию пользователя на сетевом уровне IP (Internet Protocol, протокол межсетевого обмена), и версия программного обеспечения может передаваться по протоколам верхнего уровня на основе IP.
В стандартах ETSI ("European Telecommunications Standards Institute", Европейский институт стандартов передачи данных") определено понятие "мобильная станция" (mobile station, MS), которая состоит из мобильного оборудования (mobile equipment, ME) и абонентского модуля (subscriber identity module, SIM). Этот абонентский модуль обычно выполнен сменным, т.е. его можно извлекать или перемещать из одного мобильного оборудования в другое.
В процессе активации мобильного оборудования, более конкретно в процессе его подключения к сети оператора происходит обмен данными, включающими в себя данные идентификации, между мобильным оборудованием и центром управления оператора, который разрешает или запрещает использование указанного оборудования. В настоящее время мобильное оборудование помимо обычной функции установления сеансов телефонной связи посредством доступа к мобильной сети имеет множество дополнительных пользовательских функций, предоставляемых за отдельную плату, таких как обращение к различной информации, удаленные банковские операции, электронная торговля, доступ к мультимедиа и т.д. Такие расширенные услуги требуют все более и более высокого уровня безопасности для защиты пользователей от возможного мошенничества со стороны третьих лиц, пытающихся использовать недостатки безопасности, которые могут проявиться на мобильном оборудовании.
Поэтому становится необходимой проверка по меньшей мере на двух уровнях: с одной стороны, непосредственно на уровне мобильного оборудования, и, с другой стороны - на уровне приложений, обеспечивающих функционирование различных услуг, предлагаемых оператором или третьими сторонами. Такие приложения обычно загружаются с сервера поставщика приложений, что вызывает потребность проверки этой загрузки. Цель, таким образом, состоит в обеспечении передачи данных от абонентского модуля только разрешенным приложениям после того, как этот модуль будет распознан сервером управления как имеющий возможность взаимодействия с мобильным оборудованием, в которое он установлен.
Абонентский модуль может содержать конфиденциальную информацию, такую как номер банковского счета или пароль. Приложение, функционирующее на мобильном оборудовании, отвечает за использование этих личных данных с целью предоставления требуемой услуги. В то же время приложение может использовать эти личные данные для целей, отличных от взаимодействия с требуемым поставщиком приложений. Такое использование может привести к значительному ущербу для владельца абонентского модуля.
Указанные приложения функционируют на мобильном оборудовании с использованием ресурсов, доступных в абонентском модуле. Понятие "ресурсы" включает в себя различные функции и данные, необходимые для правильного функционирования приложения. Определенные ресурсы, в частности функции, связанные с безопасностью, могут быть общими для нескольких приложений. Абонентский модуль может таким образом блокировать или изменять функционирование определенных приложений, для которых не выполняются условия безопасности, установленные оператором и/или поставщиком приложений на данном мобильном оборудовании, или для которых полномочия пользователя мобильного оборудования являются недостаточными.
В документе FR 2831362 описывается процесс защищенного взаимодействия между мобильным телефоном, содержащим SIM-карту, и сервером приложений. Назначение этого процесса состоит в защите полномочий, связанных с использованием загружаемых с сервера приложений посредством SIM-карты.
В соответствии с этим процессом вначале устанавливается защищенное соединение между сервером и SIM-картой посредством безопасного обмена открытыми ключами, после чего производится покупка приложения посредством передачи файла-запроса от мобильного оборудования на сервер. Последний выполняет частичное или полное шифрование приложения и передает на мобильное оборудование криптограмму, сформированную с помощью ключа шифрования, и команду, причем эта комбинация шифруется с помощью открытого ключа, известного SIM-карте. В процессе приема мобильным оборудованием эта криптограмма дешифруется и ключ сохраняется в SIM-карте. Выполнение команды приводит к загрузке приложения, частично или полностью зашифрованного сервером, на мобильное оборудование. После этого выполняется дешифрование загруженного приложения с помощью ключа, сохраненного в SIM-карте, и его установка на мобильное оборудование.
В соответствии с этим процессом полномочия на использование приложения на мобильном оборудовании защищены, поскольку используется предварительно установленное защищенное соединение между оборудованием и сервером, которое предваряет данную транзакцию. Функция сервера в основном заключается в управлении полномочиями или DRM (Digital Rights Management, цифровое управление полномочиями) пользователей приложения на мобильном оборудовании. Описанное далее решение ориентировано главным образом на управление рисками (Risk Management), принимаемыми на себя оператором, поставщиком приложений или пользователем в отношении приложения.
Раскрытие изобретения
Задача, на решение которой направлено настоящее изобретение, заключается в создании способа аутентификации приложения(й) на мобильном оборудовании в процессе загрузки, а также в процессе выполнения. Изобретение относится к ограничению рисков, связанных с фактом возможного нецелевого использования абонентского модуля или его использования приложениями, не отвечающими определенным предопределенным критериям безопасности.
Другая задача изобретения состоит в защите пользователя мобильного оборудования, а также соответствующих поставщиков приложений от непредусмотренных действий, производимых путем несанкционированного использования приложений.
В соответствии с изобретением решение поставленных задач достигается путем применения способа аутентификации по меньшей мере одного приложения, функционирующего на оборудовании, связанном с сервером управления по сети, причем указанное оборудование локально соединено с модулем защиты, указанное приложение загружается и/или выполняется посредством прикладной среды выполнения на оборудовании и использует ресурсы, расположенные в модуле защиты, способ включает в себя следующие предварительные шаги:
- прием данных, включающих в себя по меньшей мере идентификатор оборудования и идентификатор модуля защиты, сервером управления по сети;
- анализ и проверка указанных данных сервером управления;
- генерация криптограммы, содержащей контрольную сумму приложения, идентификационные данные оборудования и модуля защиты и команды, предназначенные для указанного модуля;
- передача указанной криптограммы по сети и через оборудование в модуль защиты;
- проверка приложения путем сравнения контрольной суммы, извлеченной из полученной криптограммы, с контрольной суммой, определенной модулем защиты,
причем указанный способ характеризуется тем, что в процессе инициализации и/или активации приложения модуль защиты выполняет команды, извлеченные из криптограммы, и соответственно предоставляет или блокирует доступ к определенным ресурсам указанного модуля защиты в зависимости от результата ранее выполненной проверки в отношении этого приложения.
Ресурсы модуля защиты блокируются или предоставляются адресным способом с целью активизации или деактивизации возможности использования определенных приложений. Приложения мобильного оборудования блокируются или разблокируются не непосредственно, а условно, т.е. блокирование или разблокирование вступает в силу только тогда, когда мобильное оборудование пытается выполнить такие приложения.
Этот способ применяется преимущественно в сети мобильной связи. Таким образом, оборудование представляет собой, например, оборудование мобильного телефона, а модуль защиты представляет собой абонентский модуль или SIM-карту. Эта совокупность соединяется с сетью мобильной связи, такой как GSM (глобальная система мобильной связи), GPRS (общая система пакетной радиосвязи), UMTS (универсальная мобильная система передачи данных) или подобной им, управление которой осуществляется сервером управления оператора. Приложения устанавливаются на мобильном оборудовании и конфигурируются соответствующим образом для использования ресурсов (данных или функций), имеющихся в абонентском модуле. Таким образом, они могут использоваться полностью только в том случае, если условия безопасности удовлетворяют критериям, установленным оператором и/или поставщиком приложения. Управление проверкой этих критериев осуществляет сервер управления. В свою очередь, управление приложением в соответствии с командами, передаваемыми сервером управления, осуществляется модулем защиты, который может предоставлять или блокировать доступ к ресурсам, необходимым для правильного функционирования приложения, установленного на мобильном оборудовании.
Данные этих ресурсов могут включать в себя такую информацию, как номера счетов, программы (в форме кода, допускающего его установку на мобильное оборудование), ключи шифрования/дешифрования, полномочия на доступ к содержанию и т.д.
Эти ресурсы могут обеспечивать реализацию таких функций, как криптофафические алгоритмы, процессы проверки, процессы генерации цифровых подписей, процессы шифрования, процессы аутентификации, процессы проверки правильности данных, процессы управления доступом, процессы сохранения данных, процессы оплаты и т.д.
В основе способа по изобретению лежит то, что с приложением связывается криптограмма, которая определяет возможность использования приложения на мобильном оборудовании, связанном с сетью.
В отличие от процесса, описанного в документе FR 2831362, не требуется частичное или полное шифрование приложения перед его загрузкой в мобильное оборудование. Фактически в соответствии со способом по изобретению соединение между сервером и модулем защиты (или абонентским модулем) служит для управления ресурсами этого модуля оптимальным способом и разрешения или запрещения их использования приложениями, функционирующими на мобильном оборудовании. Согласно процессу в процитированном документе полученная от сервера команда позволяет управлять использованием приложения, установленного на мобильном оборудовании, в то время как по настоящему способу она позволяет активизировать или деактивизировать ресурсы модуля защиты.
Например, если ресурсы деактивизированы, приложение будет функционировать в "минимальном" режиме, и пользователь получит сокращенное число возможностей. В примерном варианте осуществления это сокращение может относиться к максимально разрешенной сумме для покупки услуг, и, кроме того, эти услуги могут быть получены только в определенном месте (торговый центр, стадион, вокзал, аэропорт и т.д.)
В первом варианте осуществления реализуется передача криптограммы в абонентский модуль в процессе загрузки приложения. Во втором варианте осуществления приложение запрашивает криптограмму у сервера управления при первом использовании этого приложения.
Способ аутентификации по изобретению также применяется при выполнении приложения мобильным оборудованием, что при помощи абонентского модуля позволяет гарантировать предоставление приложению права на доступ к определенным ресурсам (данным или функциям), имеющимся в указанном абонентском модуле. В частности, абонентский модуль может регулярно проверять криптограмму, сопровождающую приложение, в процессе выполнения указанного приложения.
Например, установка абонентского модуля пользователя в другое мобильное оборудование повлияет на функционирование определенных приложений и не будет препятствовать установлению классической телефонной связи. Этот барьер действует как фильтр, который предназначен для устранения несанкционированного мобильного оборудования, а также приложений, полученных из источников, не утвержденных оператором или партнером-поставщиком приложений.
Модификация приложения третьим лицом также обнаруживается абонентским модулем, который откажется выполнять определенные принимаемые команды, вызывая, как следствие, блокирование или ограничение выполнения приложения.
Таким образом, сервер управления играет основную роль в управлении элементами доверия или безопасности, связанными с совокупностью мобильного оборудования и абонентского модуля. Он интерпретирует данные, посылаемые ему мобильным оборудованием с целью управления или ограничения использования приложений посредством ресурсов (данных или функций), хранящихся в абонентском модуле.
Сервер получает от мобильного оборудования и его абонентского модуля идентификационную информацию, содержащую идентификаторы IMEISV и IMSI, и согласно определенным критериям устанавливает, следует ли послать абонентскому модулю новую команду для переопределения нового профиля защиты, определяющего доступность ресурсов абонентского модуля для использования приложениями, функционирующими на мобильном оборудовании. Критерии могут относиться, например, к обновлению версии программного обеспечения, установленного на мобильном оборудовании, к загрузке нового приложения на мобильное оборудование, к периоду обновления профиля защиты, к числу подключений к сети, к технологии, используемой для доступа к сети, к используемой сети доступа. Они также связаны с различными рисками, относящимися к используемым аппаратным средствам и программному обеспечению, которые желает учесть оператор и/или поставщик приложений и/или пользователь.
Проверка криптограммы может выполняться в процессе первой инициализации или при первом использовании приложения, или же при каждой инициализации последнего. Согласно одному варианту осуществления такая проверка может выполняться периодически с определенной частотой по командам, посылаемым сервером управления.
В процессе загрузки приложения на мобильное оборудование сопровождающая приложение криптограмма в основном содержит контрольную сумму самого приложения, т.е. фрагмент данных, построенный на основе кода приложения посредством математической однонаправленной хеш-функции.
В процессе проверки действительности криптограммы абонентским модулем абонентский модуль также косвенно идентифицирует мобильное оборудование и подтверждает фактическое происхождение данных от сервера управления. Другими словами, посредством этой криптограммы сервер управления неявно информирует абонентский модуль о том, что тип и версия программного обеспечения мобильного оборудования были проанализированы, управление загрузкой приложения выполнено и приложение является подлинным. Согласно командам, полученным ранее, абонентский модуль определяет, следует ли подтвердить или отклонить запросы или команды, поступающие от приложения.
На этом шаге проверки мобильное оборудование выполняет функцию транзитного пункта, устанавливающего практически прямой диалог между абонентским модулем и сервером управления. Поэтому безопасность передаваемых сообщений обеспечивается на всем пути между сервером управления и абонентским модулем через среду выполнения приложений, реализованную на мобильном оборудовании. Таким образом, предотвращается "подделка" или модификация данных относительно абонентского модуля.
Настоящее изобретение также относится к модулю защиты, содержащему ресурсы, которые предназначены для локального обращения к ним по меньшей мере одним приложением, установленным на оборудовании, связанном с сетью, причем указанное оборудование имеет средства чтения и передачи данных, включающих в себя по меньшей мере идентификатор оборудования и идентификатор модуля защиты, причем указанный модуль отличается тем, что включает в себя средства приема, хранения и анализа криптограммы, содержащей помимо других данных контрольную сумму указанного приложения и команды, а также средства проверки указанного приложения и средства извлечения и выполнения команд, содержащихся в криптограмме и обеспечивающих предоставление или блокирование определенных ресурсов в зависимости от результата проверки приложения.
Такой модуль защиты используется, например, в качестве абонентского модуля или SIM-карты, соединенной с мобильным оборудованием.
Краткое описание чертежей
Другие свойства и достоинства настоящего изобретения станут ясны из нижеследующего описания, содержащего ссылки на прилагаемые чертежи, которые иллюстрируют вариант осуществления изобретения, не вносящий каких-либо ограничений.
На чертежах:
- на фиг.1а приведена блок-схема процесса установки приложения согласно первому варианту осуществления, в котором используется передача криптограммы через среду выполнения приложений;
- на фиг.1b показан процесс проверки криптограммы согласно способу на фиг.1а;
- на фиг.1с показан процесс выполнения приложения с использованием ресурсов абонентского модуля согласно способу на фиг.1а;
- на фиг.2а приведена блок-схема процесса установки приложения согласно второму способу, в котором реализуется загрузка только приложения;
- на фиг.2b показан процесс проверки, в котором приложение запрашивает криптограмму у сервера управления согласно способу на фиг.2а;
- на фиг.2с показан процесс выполнения приложения с использованием ресурсов абонентского модуля согласно способу на фиг.2а;
- на фиг.3а приведена блок-схема процесса установки приложения согласно третьему способу, в котором реализуется загрузка только приложения;
- на фиг.3b показан процесс проверки, в котором приложение запрашивает криптограмму и контрольную сумму приложения у сервера управления согласно способу на фиг.3а.
- на фиг.3с показан процесс выполнения приложения с использованием ресурсов абонентского модуля согласно способу на фиг.3а.
- на фиг.4 показана структура примерной криптограммы.
Осуществление изобретения
На блок-схемах на фиг.1а, 1b, 1с, 2а, 2b, 2с, 3а, 3b, 3с показан абонентский модуль (SIM) мобильного оборудования (СВ), содержащий ресурсы (RES) и соединенный через сеть (NET) мобильной связи с сервером (CSE) управления, которым управляет оператор. Этот сервер связан с одним или несколькими поставщиками (FA) приложений.
Мобильное оборудование (СВ) содержит одно или несколько приложений (АРР), функционирующих в среде (АЕЕ) выполнения. Эти приложения поступают от поставщика (FA) приложений, связанного с сервером (CSE) управления оператора, или могут быть запрограммированы изначально изготовителем мобильного оборудования. В последнем случае иногда необходимо загрузить обновления, которые также проверяются абонентским модулем (SIM).
Согласно первому варианту осуществления, показанному на фиг.1а, 1b, 1с, криптограмма (CRY) приложения (АРР) передается в абонентский модуль (SIM) через среду (АЕЕ) выполнения приложений в процессе установки приложения (АРР).
На фиг.1а показан процесс установки, в котором вначале происходит передача данных, служащих в качестве идентификации (ID) абонентского модуля (SIM), мобильным оборудованием (СВ) и их проверка сервером (CSE) управления. Эта идентификация (ID) основана на идентификаторе (IMSI) абонентского модуля (SIM) и уникальном идентификаторе (IMEISV) мобильного оборудования (СВ). После этого выполняется загрузка приложения (АРР) с сервера (CSE) управления вместе с криптограммой (CRY), которая передается в абонентский модуль (SIM) через среду (АЕЕ) выполнения для проверки, как показано на фиг.1b.
Следует отметить, что поставщик (FA) приложений рассматривается оператором как заслуживающий доверия, т.е. приложения (АРР) считаются одобренными и функционирующими без причинения какого-либо ущерба пользователю и/или оператору.
Способ по изобретению применяется в отношении нескольких видов приложений (АРР), выполняемых в различных типах среды (АЕЕ) выполнения. Например, многие мобильные телефоны имеют функции, которые реализуются приложениями Java, выполняемыми виртуальной машиной (VM) Java, которая при этом служит процессором и средой. Нижеследующее описание основано на примере приложений Java. Разумеется, для поддержки приложений могут использоваться и другие среды или операционные системы, такие как Symbian OS, Windows, Palm OS, Linux и т.д.
В процессе выполнения (см. фиг.1с) приложение Java посылает запрос абонентскому модулю (SIM) и информирует среду (АЕЕ) выполнения путем посылки запросов или команд (CMD). В среде (АЕЕ) выполнения выполняется вычисление контрольной суммы (FIN2) приложения, после чего эта информация посылается абонентскому модулю (SIM). Криптограмма (CRY), сгенерированная сервером (CSE) управления и затем загруженная на мобильное оборудование (СВ) вместе с приложением (АРР) (или отдельно от него), сохраняется в абонентском модуле (SIM). Последний вначале проверяет наличие у него данных, позволяющих определить, следует ли отвечать на запросы или команды (CMD) приложения (АРР). Эти данные, которые действуют как полномочия, загружаемые с сервера (CSE) управления в процессе загрузки приложения (АРР), позволяют управлять функционированием приложения (АРР). В случае отсутствия этих полномочий приложение (АРР) будет не в состоянии использовать ресурсы (RES) (данные или функции) абонентского модуля (SIM).
Если указанные полномочия присутствуют, абонентский модуль (SIM) проверяет контрольную сумму (FIN1), полученную из сохраненной криптограммы (CRY), путем ее сравнения с контрольной суммой (FIN2), связанной с приложением (АРР) и поступающей от среды (АЕЕ) приложения. Эта криптограмма (CRY) может иметь структуру блока, зашифрованного закрытым ключом RSA (Rivest, Shamir, Adelman).
Этот блок, представленный на фиг.4, помимо других данных содержит, например, идентификатор (ID_SIM) абонентского модуля IMSI, идентификатор (ID_CB) мобильного оборудования IMEISV, идентификатор (ID_APP) приложения, контрольную сумму (FIN1) приложения, идентификаторы (RES_ID) ресурсов SIM-карты и команды блокирования/предоставления ресурсов (INS_RES) SIM-карты. Указанный закрытый ключ известен только серверу (CSE) управления, тогда как открытая часть указанного ключа известна абонентскому модулю (SIM). Преимущество использования асимметричных ключей состоит в том, что ключ, используемый при создании криптограммы, не выходит за пределы сервера (CSE) управления.
Разумеется, в качестве альтернативы RSA могут использоваться другие алгоритмы с асимметричными ключами, такие как DSA (Digital Algorithm Signature, алгоритм цифровых подписей) и ЕСС (Elliptic Curve Cryptography, криптография на основе эллиптических кривых).
Использование алгоритмов с симметричными ключами может быть выбрано ввиду относительной простоты, высокой скорости проверки и более низких затрат на производство и реализацию. В этом случае ключ известен серверу (CSE) и абонентскому модулю (SIM); для подписывания комплекса данных (IMSI, IMEISV, идентификатор приложения, контрольные суммы приложений, идентификаторы ресурсов SIM-карты, команды блокирования/предоставления ресурсов SIM-карты) может использоваться, например, алгоритм IDEA (International Data Encryption Algorithm, международный алгоритм шифрования данных). В качестве альтернативы алгоритму IDEA могут использоваться такие алгоритмы, как TDES (Triple Data Encryption Standard, стандарт тройного шифрования данных) и AES (Advanced Encryption Standard, стандарт расширенного кодирования).
В указанных двух вариантах с асимметричными и симметричными ключами абонентский модуль (SIM) проверяет соответствие различных полей в криптограмме (CRY), в частности контролирует идентификаторы (ID_APP) приложений и контрольные суммы (FIN1) приложений, для которых разрешено или запрещено использование его ресурсов (RES) (данных или функций).
В одном варианте криптограмма (CRY) может содержать счетчик, предназначенный для предотвращения повторного использования одной и той же криптограммы, предназначенной для абонентского модуля (SIM) (атака с повторным использованием). В реальной ситуации два приложения одного типа могут иметь один и тот же идентификатор и контрольную сумму (FIN1). В этом случае абонентский модуль (SIM) также контролирует значение этого счетчика путем его сравнения со значением эталонного счетчика, которое сохраняется и регулярно обновляется.
В другом варианте способа с применением счетчика используется случайная переменная (случайное число), генерируемое абонентским модулем (SIM). Эта случайная переменная передается вместе с данными, посылаемыми серверу (CSE) управления. Последний посылает эту случайную переменную обратно в ответном сообщении, что позволяет абонентскому модулю подтвердить его связь с новым сообщением. В более широком понимании, для избежания любого риска использования старой криптограммы (CRY) последняя включает в себя переменную, которая может быть предсказана абонентским модулем (SIM) и является счетчиком или случайной переменной.
В другом варианте криптограмма (CRY), генерируемая с помощью ключа типа RSA или IDEA, может быть заменена блоком, генерируемым с помощью общедоступного ключа НМАС (Keyed-Hashing for Message Authentication, хэширование на основе ключей для идентификации сообщений) на основе комплекса (IMSI, IMEISV, идентификатор приложения, контрольная сумма приложения, идентификаторы ресурсов SIM-карты, команды блокирования/предоставления ресурсов SIM). НМАС представляет собой механизм, предназначенный для идентификации сообщений с применением криптографических хеш-функций, таких как MD5 (Message Digest, дайджест сообщения) или SHA-1 (Secure Hash Algorithm, алгоритм безопасного хэширования) в сочетании с общедоступным ключом.
Этот ключ, который присутствует на сервере (CSE) управления и в абонентском модуле (SIM), может загружаться во время персонализации абонентского модуля (SIM) или во время установки определенных ресурсов (RES) в абонентский модуль (SIM). Согласно различным вариантам каждый ресурс (RES) или группа ресурсов абонентского модуля (SIM) может быть связана с отдельным ключом; ключ также может быть общим для всех ресурсов (RES) и уникальным для данного абонентского модуля(SIM).
Таким образом, криптограмма (CRY) позволяет абонентскому модулю (SIM) иметь информацию о реусрсе(ах) (RES), которые могут быть предоставлены или блокированы для соответствующего мобильного оборудования (СВ) в абонентском модуле (SIM).
Используемые две контрольные суммы (соответственно FIN1 и FIN2) являются определяющими элементами, так как они представляют собой криптографические средства управления приложением (АРР) посредством мобильного оборудования (СВ) и абонентского модуля (SIM). Управление такого типа необходимо для предотвращения аутентификации третьего приложения с использованием данной криптограммы (CRY). Фактически, если криптограмма А подтверждает подлинность приложения А для абонентского модуля А в мобильном оборудовании А, необходимо избежать ситуации, в которой другое приложение В несанкционированно подтверждается этой же криптограммой А для абонентского модуля А в мобильном оборудовании А.
Согласно одному варианту контрольная сумма (FIN1) приложения, включенная в криптограмму (CRY), остается конфиденциальной на всем пути между сервером (CSE) управления и абонентским модулем (SIM). Для этого контрольная сумма (FIN1) зашифровывается сервером (CSE) управления и расшифровывается абонентским модулем (SIM). Кроме того, приложение (АРР) может быть персонализировано для данной операции загрузки таким образом, что контрольная сумма (FIN1), включенная в криптограмму (CRY), остается идентичной контрольной сумме (FIN2) приложения (АРР), вычисленного средой (АЕЕ) выполнения, но зависит от идентификации мобильного оборудования (СВ). Такая мера необходима в случае, если необходимо избежать ситуации, в которой третье приложение подтверждается контрольной суммой из другой среды (АЕЕ) выполнения приложений, безопасное взаимодействие которой с абонентским модулем (SIM) может быть нарушено. Фактически, если контрольная сумма А подтверждает подлинность приложения А из абонентского модуля А в мобильном оборудовании А, необходимо избежать несанкционированной идентификации другого приложения В посредством контрольной суммы А из абонентского модуля В в мобильном оборудовании В.
Согласно другому варианту каждое приложение (типа Java) сопровождается двумя криптограммами: криптограммой Java, предназначенной для виртуальной машины (VM), и криптограммой (CRY), предназначенной для абонентского модуля (SIM). Эти две криптограммы, помимо прочего, содержат одну и ту же контрольную сумму (в данном случае называемую FIN2) приложения, которая является контрольной суммой кода Java-приложения. При этом, если абонентскому модулю (SIM) необходимо проверить криптограмму (CRY) приложения, он ожидает поступление контрольной суммы (FIN2), связанной с анализируемым приложением (АРР) и обязательно вычисленной предварительно от виртуальной машины (VM). Контрольная сумма приложения передается мобильным оборудованием (СВ) в абонентский модуль (SIM). Эта контрольная сумма не поступает от сервера управления, а вычисляется средой (АЕЕ) выполнения приложений мобильного оборудования (СВ) после загрузки приложения (АРР). С другой стороны, мобильное оборудование (СВ) передает предварительно загруженную с сервера управления вместе с приложением криптограмму (CRY) в абонентский модуль. После этого последний может проверить полученную контрольную сумму путем сравнения. Мобильное оборудование (СВ) не имеет возможности подделки, поскольку не имеет контрольной суммы, полученной абонентским модулем (SIM); если же такая ситуация имеет место, может потребоваться построение обратимой функции вычисления контрольной суммы, обычно хеш-функции, или обнаружение другой контрольной суммы, на основе которой строится та же самая криптограмма (CRY), что практически невозможно.
На фиг.1b показан процесс проверки криптограммы (CRY), который может выполняться периодически, например, перед каждым запросом рассматриваемого приложения (АРР), или предпочтительно однократно перед его установкой или первым использованием. Если криптограмма (CRY) является подлинной, абонентский модуль (SIM) передает сообщение (ОК) подтверждения в среду (АЕЕ) выполнения. В результате приложение (АРР) получает возможность адресовать запросы или команды (CMD) абонентскому модулю (SIM) через среду (АЕЕ) выполнения и использовать ресурсы (RES) абонентского модуля (SIM). Последний подтверждает команды (CMD) путем посылки ответов (RSP), соответствующих приложению (АРР), через среду (АЕЕ) выполнения, см. фиг.1с.
Если криптограмма (CRY) является недействительной, абонентский модуль (SIM) передает в среду (АЕЕ) выполнения сообщение (МОК) отклонения. В этом случае среда (АЕЕ) выполнения может отменить процесс установки приложения (АРР), или приложение (АРР) устанавливается, но его запросы или команды (CMD), адресованные абонентскому модулю (SIM) через среду (АЕЕ) выполнения, останутся без ответа (RSP), и ресурсы (RES) абонентского модуля (SIM) не будут доступны для использования.
Среда (АЕЕ) выполнения приложений может передавать ответ на сервер (CSE) управления как в случае принятия, так и в случае отклонения (ОК и NОК). Абонентский модуль таким образом может косвенно посылать ответное подтверждающее сообщение (CF) приема криптограммы (CRY) на сервер (CSE) управления и обеспечивать непрерывное управление операцией, см. фиг.1b. Подтверждающее сообщение (CF) содержит по меньшей мере один код успешного завершения или ошибки выполнения операции, а также счетчик, предназначенный для защиты от атак с дублированием. Это сообщение также позволяет серверу (CSE) управления осуществлять обновление счетчика, связанного с абонентским модулем (SIM).
Согласно второму варианту осуществления, показанному на фиг.2а, 2b, 2с, после идентификации (ID) мобильного оборудования (СВ) загружается только приложение (АРР) без криптограммы (CRY), см. фиг.2а.
В процессе проверки, показанной на фиг.2b, приложение (АРР) во время его инициализации пользователем запрашивает криптограмму (CRY), содержащую полномочия (RES) на доступ к использованию ресурса для указанного приложения. Указанная криптограмма (CRY) загружается с сервера (CSE) управления непосредственно приложением (АРР), которое передает ее в абонентский модуль (SIM) через среду (АЕЕ) выполнения. Абонентский модуль (SIM) передает подтверждающее сообщение (CF) принятия криптограммы (CRY) на сервер (CSE) управления посредством приложения (АРР), а не посредством среды (АЕЕ) выполнения, в отличие от первого варианта осуществления. Таким образом, среда (АЕЕ) выполнения обеспечивает только функцию транзитного пункта между приложением (АРР) и абонентским модулем (SIM).
Процесс выполнения приложения (АРР) после проверки криптограммы (CRY), см. фиг.2с, проходит тем же образом, что и в первом способе, показанном на описанной выше фиг.1с.
На фиг.3а, 3b, 3с показан третий вариант осуществления, в котором после идентификации (ID) мобильного оборудования (СВ) осуществляется загрузка только приложения (АРР) с сервера (CSE) управления или с промежуточного сервера (АРР) загрузки приложений, см. фиг.3а. В процессе проверки (на фиг.3b) приложение загружает криптограмму (CRY) и контрольную сумму (FIN2) непосредственно с сервера (CSE) управления или с промежуточного сервера (АРР) загрузки приложений. В этом случае в отличие от двух предыдущих вариантов в среде (АЕЕ) приложений не выполняется вычисление контрольной суммы (FIN2), которая вычисляется внешним модулем, либо сервером (CSE) управления, либо промежуточным сервером (АРР) загрузки приложений.
Процесс выполнения приложения (АРР) после проверки криптограммы (CRY), см. фиг.3с, проходит тем же образом, что и согласно двум предыдущим способам, описанным со ссылками на фиг.1с и 2с.
Преимущество третьего варианта осуществления состоит в то, что этот способ не требует какой-либо модификации среды (АЕЕ) выполнения в том виде, в каком она определена для приложений Java, устанавливаемых на мобильные телефоны, т.е. не требует модификации существующих стандартов.
Кроме того, при условии полной независимости процесса проверки криптограммы (CRY) и процесса установки приложения устраняется ограничение первого варианта, который требует наличия двух криптограмм с одной и той же контрольной суммой.
Для персонализации контрольных сумм, вычисляемых на основе приложений, имеется возможность добавления к коду приложения различных данных для каждого экземпляра мобильного оборудования перед загрузкой на мобильное оборудование. Поэтому контрольная сумма, вычисляемая в среде приложений мобильного оборудования, является уникальной и не может использоваться для другого мобильного оборудования. Разумеется, сервер управления вычисляет криптограмму на основе исходных данных приложения и этих уникальных данных.
В варианте осуществления изобретения мобильное оборудование может быть заменено стационарным устройством, таким как декодер платного телевидения или компьютер. Приложения могут загружаться в устройство с сервера через сеть передачи данных. Криптограмма, связанная с приложением, сохраняется в модуле защиты и проверяется в процессе выполнения или при каждой операции инициализации приложения. Результат этой проверки определяет условия функционирования приложения за счет предоставления или блокирования ресурсов в модуле защиты.
1. Способ аутентификации по меньшей мере одного приложения (АРР), функционирующего на оборудовании (СВ), соединенном по сети (NET) с сервером (CSE) управления, причем указанное оборудование (СВ) локально соединено с модулем (SIM) защиты, а указанное приложение (АРР) загружается и/или выполняется посредством среды (АЕЕ) выполнения приложений на оборудовании (СВ) и использует ресурсы (RES), расположенные в модуле (SIM) защиты, способ включает в себя следующие предварительные шаги:
принимают данные, включающие в себя по меньшей мере идентификатор (IMEISV) оборудования (СВ) и идентификатор (IMSI) модуля (SIM) защиты, посредством сервера (CSE) управления через сеть (NET);
анализируют и проверяют указанные данные посредством сервера (CSE) управления;
генерируют криптограмму (CRY), содержащую контрольную сумму (FIN1) приложения (АРР), идентификационные данные оборудования (СВ) и модуля (SIM) защиты и команды (INS-RES), предназначенные для указанного модуля;
передают указанную криптограмму (CRY) по сети (NET) и через оборудование (СВ) в модуль (SIM) защиты;
проверяют приложение (АРР) путем сравнения контрольной суммы (FIN1), извлеченной из полученной криптограммы (CRY), с контрольной суммой (FIN2), определенной модулем защиты,
отличающийся тем, что в процессе инициализации и/или активации приложения (АРР) модуль (SIM) защиты выполняет команды (INS-RES), извлеченные из криптограммы (CRY), и соответственно предоставляет или блокирует доступ к определенным ресурсам (RES) указанного модуля защиты (SIM) в зависимости от результата ранее выполненной проверки в отношении этого приложения (АРР).
2. Способ по п.1, отличающийся тем, что оборудование представляет собой мобильное оборудование (СВ) мобильной телефонии.
3. Способ по п.1, отличающийся тем, что сеть (NET) представляет собой сеть мобильной связи типа GSM, GPRS или UMTS.
4. Способ по п.1, отличающийся тем, что модуль (SIM) защиты представляет собой абонентский модуль типа SIM-карты, устанавливаемый в мобильное оборудование (СВ) мобильной телефонии.
5. Способ по п.1 или 4, отличающийся тем, что идентификацию (ID) комплекса, включающего в себя мобильное оборудование (СВ) и абонентский модуль (SIM), осуществляют на основе идентификатора (IMEISV) мобильного оборудования (СВ) и идентификатора абонентского модуля (SIM), относящегося к данному абоненту сети (NET).
6. Способ по п.1, отличающийся тем, что команды, содержащиеся в криптограмме (CRY), полученной модулем защиты (SIM), определяют возможность использования приложений (АРР) согласно критериям, предварительно установленным оператором, и/или поставщиком (FA) приложений, и/или пользователем оборудования.
7. Способ по п.6, отличающийся тем, что критерии определяют пределы использования приложения (АРР) в зависимости от рисков, связанных с программным обеспечением указанного приложения (АРР) или с аппаратными средствами оборудования (СВ), которые желает учесть оператор.
8. Способ по п.1, отличающийся тем, что проверку приложения (АРР) посредством криптограммы (CRY) выполняют при первой инициализации или первом использовании указанного приложения (АРР).
9. Способ по п.1, отличающийся тем, что проверку приложения (АРР) посредством криптограммы (CRY) выполняют периодически с заданной периодичностью по командам, поступающим от сервера (CSE) управления.
10. Способ по п.1, отличающийся тем, что проверку приложения (АРР) посредством криптограммы (CRY) выполняют при каждой инициализации указанного приложения (АРР) на оборудовании (СВ).
11. Способ по п.1, отличающийся тем, что криптограмму (CRY) генерируют с помощью асимметричного или симметричного ключа шифрования на основе набора данных, содержащего, помимо других данных, идентификатор (IMEISV) оборудования (СВ), идентификатор (IMSI) модуля (SIM) защиты, идентификатор приложения (АРР), контрольную сумму (FIN1) приложения (АРР), вычисляемую посредством однонаправленной хеш-функции и идентификаторов (RESJD) ресурсов модуля (SIM) защиты, и команд (INS-RES) для блокирования/предоставления ресурсов модуля (SIM) защиты.
12. Способ по п.11, отличающийся тем, что криптограмма (CRY) содержит переменную, которая предсказывается модулем (SIM) защиты, что позволяет предотвратить двойное использование одной и той же криптограммы (CRY), причем значение указанной переменной контролируется модулем (SIM) защиты путем его сравнения с эталонным значением, хранящимся в указанном модуле и регулярно обновляемым.
13. Способ по п.1, отличающийся тем, что модуль (SIM) защиты передает на сервер (CSE) управления через оборудование (СВ) и сеть (NET) подтверждающее сообщение (CF) после подтверждения или отклонения криптограммы (CRY) приложения (АРР) этим модулем (SIM) защиты.
14. Способ по п.1, отличающийся тем, что криптограмма (CRY) передается в модуль защиты (SIM) в то же самое время, как приложение (АРР) загружается в оборудование (СВ) посредством среды выполнения приложений (АЕЕ).
15. Способ по п.1, отличающийся тем, что приложение (АРР), ранее загруженное на оборудование (СВ) с сервера (CSE) управления через сеть (NET), при инициализации запрашивает у сервера (CSE) управления криптограмму (CRY) и передает указанную криптограмму (CRY) в модуль (SIM) защиты, причем модуль (SIM) защиты передает на сервер подтверждающее сообщение (CF) принятия или отклонения криптограммы (CRY) посредством приложения (АРР).
16. Способ по п.1, отличающийся тем, что оборудование представляет собой декодер платного телевидения или компьютер, с которым соединен модуль защиты.
17. Модуль защиты, содержащий ресурсы (RES), которые предназначены для локального обращения к ним по меньшей мере одним приложением (АРР), установленным на оборудовании (СВ), соединенном с сетью (NET), причем оборудование (СВ) содержит средства чтения и передачи данных, включающих в себя по меньшей мере идентификатор (IMEISV) оборудования (СВ) и идентификатор (IMSI) модуля защиты (SIM), отличающийся тем, что содержит средства приема, хранения и анализа криптограммы (CRY), содержащий, помимо других данных, контрольную сумму (FIN1) приложения (АРР) и команды (INS-RES), а также средства проверки указанного приложения (АРР) и средства извлечения и выполнения команд (INS-RES), содержащихся в криптограмме (CRY) и обеспечивающих предоставление или блокирование определенных ресурсов (RES) в зависимости от результата проверки приложения (АРР).
18. Модуль защиты по п.17, отличающийся тем, что он представляет собой модуль типа "абонентский модуль" или "SIM-карта" и предназначен для соединения с мобильным оборудованием.
