Защита при обеспечении мобильности между серверами mbms

Защита при обеспечении мобильности между серверами mbms

Иллюстрации

Показать все

Реферат

ОБЛАСТЬ ТЕХНИКИ

[0001] Примеры и варианты осуществления настоящего изобретения (которыми не ограничиваются возможности его реализации) в целом относятся к системам беспроводной связи, способам, устройствам и компьютерным программам, а более точно - к многоадресным или широковещательным услугам (например, к мультимедийным широковещательным/многоадресным услугам MBMS или ОМА BCAST), предоставляемым в беспроводной сети, в которой конечные пользователи мобильны и перемещаются между зонами охвата различных серверов, передающих потоки данных в широковещательном режиме.

ПРЕДПОСЫЛКИ ИЗОБРЕТЕНИЯ

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

[0002] Важной вехой, достигнутой в области развития мультимедийной широковещательной/многоадресной услуги (MBMS, multimedia broadcast/multicast service), стало широкомасштабное коммерческое внедрение потокового мобильного телевидения, в частности, с использованием модели MediaFLO®, осуществляемое крупными операторами. В целом, MBMS представляет собой услугу вида "точка - много точек", с помощью которой можно безопасно передавать данные, такие как мобильное телевидение, заданному множеству пользователей, подписанных на эту услугу. Защита обеспечивается с помощью заданных индивидуально для пользователей ключей, которые, как и ключи услуги, обрабатываются двухточечным образом, при этом ключи, связанные с контентом услуги, основаны на многоадресной/широкополосной передаче. Более подробная информация об обеспечении защиты MBMS (eMBMS для развитых систем UTRAN или LTE) представлена в технической спецификации 3GPP TS 33.246 v10.0.0. Для охвата широкой географической зоны операторы связи обычно нуждаются в установке нескольких широковещательных серверов, в зависимости от количества пунктов, поддерживаемых каждым сервером. Конечный пользователь может перемещаться между зонами охвата этих серверов, из которых конечные пользователи принимают поток MBMS, например, когда они следуют на работу или возвращаются с работы.

[0003] Архитектура защиты для MBMS основана на общей архитектуре начальной загрузки (GBA, generic bootstrapping architecture), однако GBA не разрабатывалась для поддержки функций мобильности между серверами MBMS (называемых BM-SC). Более конкретно, иерархически ключи в MBMS разделяются на два класса, как показано в таблице на фиг. 1, иллюстрирующей известный уровень техники: заданные индивидуально для пользователя и заданные индивидуально для услуги ключи. На фиг. 1А описываются четыре ключа защиты:

- MTK (MBMS traffic key, ключ трафика MBMS), используемый для шифрования данных MBMS (например, данных мобильного телевидения) в BMSC или в сервере базы данных и для дешифрования данных в пользовательском оборудовании (UE, user equipment), также называемом терминалом;

- MSK (MBMS service key, ключ услуги MBMS), генерируемый BMSC и используемый для дешифрования ключей MTK, заданных индивидуально для услуги;

- MUK (MBMS user key, пользовательский ключ MBMS), используемый для шифрования ключей MSK в BMSC перед их посылкой в UE, а также используемый терминалом для выполнения дешифрования; и

- MRK (MBMS request key, ключ запроса MBMS), используемый BMSC для аутентификации и авторизации запроса MSK терминалом;

MUK и MRK являются ключами, заданными индивидуально для пользователя и заданными индивидуально для сервера (то есть, они привязаны к конкретному серверу BMSC на основе GBA), в то время как MSK и MTK являются ключами, заданными индивидуально для конкретной услуги.

[0004] Как показано на фиг. 1В, в системе BCAST ОМА используется та же иерархия логических ключей, в которой TEK представляет собой ключ трафика, SEK и PEK - ключ услуги, SMK и REK подобны пользовательскому ключу, a SI (общий или частный) подобен пользовательскому ключу аутентификации/запроса. Широковещательная передача в системе ОМА, в том что касается совмещения мобильности и защиты, также характеризуется подобными недостатками. Описание, представленное ниже, позволяет разобраться в некоторых проблемах, возникающих при использовании GBA для мобильной потоковой передачи с поддержкой функций мобильности между серверами, и в том, каким образом можно устранить эти проблемы.

[0005] Настоящее изобретение применимо к любому устройству или терминалу, способному генерировать криптографические ключи, основанные на GBA, и принимать сообщения MBMS или BCAST, то есть оно относится не только к мобильным телефонам.

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

[0006] В соответствии с аспектом примера осуществления настоящего изобретения предлагается способ, включающий активизацию пользовательским оконечным устройством нового потокового сервера для генерации новых заданных индивидуально для пользователя ключей защиты; прием в пользовательском оконечном устройстве нового ключа защиты, заданного индивидуально для нового потокового сервера, от нового потокового сервера; генерацию в пользовательском оконечном устройстве заданных индивидуально для пользователя ключей защиты для потокового сервера и использование пользовательским оконечным устройством новых заданных индивидуально для пользователя ключей защиты, сгенерированных в пользовательском оконечном устройстве, с новым потоковым сервером для ранее установленной потоковой услуги.

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

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

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

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

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

[0011] На фиг. 1А-В показаны таблицы, в которых обобщенно приводятся некоторые известные ключи защиты, используемые для предоставления услуг MBMS и широковещательных услуг ОМА BCAST, соответственно.

[0012] На фиг. 2 показана блок-схема типового размещения устройств для многоадресной передачи, в которой пользовательское оконечное устройство перемещается между зонами охвата множества потоковых серверов для приема данных услуги MBMS или BCAST.

[0013] На фиг. 3 в соответствии с примерами осуществления настоящего изобретения представлен алгоритм, который с точки зрения пользовательского оконечного устройства иллюстрирует операции и результат выполнения инструкций компьютерной программы, записанной в машиночитаемой памяти.

[0014] На фиг. 4 показана упрощенная блок-схема различных электронных устройств, таких как поставщики потоковых услуг и пользовательские оконечные устройства, показанные на фиг. 2, которые подходят для применения на практике примеров осуществления настоящего изобретения.

[0015] На фиг. 5 показана упрощенная блок-схема выполнения способа в соответствии с примерами осуществления настоящего изобретения.

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

[0016] На фиг. 2 показан один из примеров реализации услуги многоадресной передачи MBMS или BCAST для мобильного пользователя. Пользовательское оконечное устройство 108 или некоторое иное мобильное электронное устройство принимает многоадресный поток из множества потоковых серверов 104, 106, в то время как пользовательское оконечное устройство перемещается между этими серверами. Сервер 102 предоставления контента может располагаться в сотовой сети, а также вне ее. Собственно зашифрованные данные могут порождаться другим сервером предоставления контента, например сервером, эксплуатируемым кинокомпанией. Контент может шифроваться с использованием MTK в сервере предоставления контента. Однако контент также может поступать непосредственно из BMSC 104, 106 (локальный контент) и там же шифроваться (например, местный прогноз погоды). Ниже фиг. 2 описывается со ссылкой на услугу MBMS и относящиеся к ней ключи защиты, однако фиг. 2 также представляет систему BCAST с ее по-иному названными, но функционально схожими ключами защиты, которые в общем виде описаны на фиг. 1В.

[0017] Для удобства сервер 104 рассматривается как 'старый' или первый сервер, из зоны которого перемещается пользовательское оконечное устройство 108, а сервер 106 рассматривается как 'новый' или второй сервер, в зону которого перемещается пользовательское оконечное устройство 108. Поставщик контента MBMS или другой централизованный сервер 102 контента предоставляет контент MBMS потоковым серверам 104, 106. В типовой схеме централизованный сервер 102 контента шифрует контент с использованием MTK, и отдельные серверы 104, 106 используют MUK для защиты MSK при передаче ключа услуги MBMS по радиоканалу в пользовательское оконечное устройство 108. Пользовательское оконечное устройство 108 использует свой заданный индивидуально для сервера MUK для дешифрования различных MSK, поступающих из различных серверов 104, 106, предоставляющих услугу, а затем получает MTK с помощью MSK для дешифрования MTK, доставленного совместно с потоковой услугой MBMS. Однако, поскольку различные серверы 104, 106, предоставляющие услугу, могут применять различные MSK, пользовательское оконечное устройство 108 должно хранить различные MUK для различных серверов 104, 106, предоставляющих устройству услугу MBMS. Криптографический способ генерации MUK обеспечивает получение различных результирующих MUK для каждого сервера. Кроме того, может существовать множество MTK для заданной услуги MBMS, один - для национального контента и множество других MTK - для локального контента, и эти MTK локального контента могут отличаться для различных серверов 104, 106 предоставления услуг.

[0018] В том случае если в основе лежит архитектура GBA, обеспечение мобильности между MBMS-серверами, порождает две проблемы, связанные с защитой:

- Различное потребление MTK_ID на различных серверах приводит к тому, что серверы, которые используют одинаковый ключ услуги (MSK), не синхронизированы. Для того чтобы предотвратить воспроизведение одинакового сообщения, нижней границе ключа услуги (MSK) назначается номер MTK_ID последнего дешифрованного MTK. Если один сервер применяет большее количество MTK_ID по сравнению с другим сервером и пользователь перемещается от сервера, характеризующегося большим объем применения MTK_ID, к серверу с меньшим объем применения, то этот пользователь начинает принимать MTK_ID, которые уже были приняты. Если пользователю не разрешено дешифровать эти сообщения в целях защиты от атак с повтором, то может наблюдаться прерывание в обслуживании конечного пользователя. Эта ситуация может легко возникнуть при наличии локального контента или в случае высокой степени мобильности.

- Предполагается, что MSK специфичны (заданы индивидуально) для сервера; следовательно, MTK для трафика не будут доступны при изменении сервера. Если у пользователя имеются оба MSK, то они должны функционировать вне зависимости от того, к какому BMSC пользователь подсоединен, и пользовательский терминал (UE) при этом может дешифровать любые получаемые данные MBMS. Однако проблема возникает в том случае, если один из потоков замирает и для нового сервера MSK отсутствует или его срок действия истек.

- Если предположить, что MSK НЕ специфичен для сервера, то проблема защиты возникает в том случае, если срок действия MSK истек и ключ не может быть обновлен, поскольку авторизация, основанная на MUK, заканчивается неудачно (см. следующий пункт).

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

- Применение слишком большого количества MTK_ID приводит к расходованию ресурсов смарт-карты (к исчерпанию памяти). Оценки показывают, что при предполагаемой 5-секундной периодичности обновления ключа (что соответствует практическим схемам внедрения) срок службы карты составляет 3-4 месяца, после чего ее ресурсы исчерпываются, и она становится непригодной (по меньшей мере для MBMS). В результате сотовому оператору примерно каждые 3 месяца необходимо высылать пользователю новую смарт-карту (UICC).

[0019] Проблема, связанная с различием объемов потребления MTK_ID, становится более очевидной, если потоковые серверы также предоставляют локальный контент, например, если потоки MBMS доставляют общую новостную ленту с определенными "интервалами" для местных рекламных сообщений, которые могут различаться (например, реклама для потоков в Калифорнии может отличаться от рекламы во Флориде в тех же временных интервалах общего новостного потока). В результате возникает ситуация, в которой промежуток между текущим MTK_ID на одном сервере по сравнению с другим сервером со временем увеличивается и сбрасывается только при следующем обновлении MSK.

[0020] Примеры осуществления идей настоящего изобретения позволяют реализовать протокол, устраняющий излишнее применение MTK_ID и предоставляющий возможность обновлять MSK. Описываемые ниже примеры также обратно совместимы с уже существующими схемами внедрения MBMS, поэтому они могут применяться в текущей инфраструктуре MBMS. Таким же образом, для системы BCAST эти идеи позволяют устранить излишнее применение TEK и предоставляют возможность обновления SEK/PEK, а также обратно совместимы с уже существующими схемами внедрения BCAST.

[0021] Вначале рассмотрим фиг. 2, на котором показана обзорная схема расположения двух серверов 104, 106, предоставляющих услугу MBMS пользовательскому оконечному устройству 108, и централизованного сервера 102 контента, который находится на объекте поставщика контента. Централизованный сервер 102 контента шифрует контент с использованием MTK. Как первый сервер 104, так и второй сервер 106 представляют собой BMSC со своим собственным MSK, который может использоваться для шифрования MTK. Пользовательское оконечное устройство 108 содержит MUK, и различные MUK могут быть действительны для различных BMSC 104, 106. Пользовательское оконечное устройство 108 успешно принимает данные услуги MBMS от старого первого сервера 104 с использованием своего MUK, действительного для этого сервера 104, для дешифрования MSK, полученного из этого сервера, и дешифрует MTK. При перемещении пользовательского оконечного устройства 108 от этого старого первого сервера 104 к новому второму серверу 106 появляется новый MSK для этого второго сервера 106, и, кроме того, срок действия MTK либо истекает, либо близок к завершению (поскольку срок действия MTK очень небольшой, он истекает достаточно быстро, либо MTK для различных серверов может различаться, если пользовательское оконечное устройство изменяет серверы в процессе передачи локального контента). При использовании традиционной MBMS пользовательское оконечное устройство 108 более не может дешифровать данные услуги MBMS, предоставляемой новым вторым сервером 106, поскольку срок действия MTK истек, и пользовательскому оконечному устройству 108 не известен MSK для этого второго сервера 106.

[0022] В текущих схемах внедрения MBMS большая часть контента шифруется сервером 102 предоставления контента с помощью MTK; так, например, в схемах внедрения, упомянутых в разделе, посвященном уровню техники, может существовать канал связи с CNN®, и именно CNN® шифрует предоставляемый компанией контент. Затем поставщик контента предоставляет данные контента и MTK в сервер MBMS (BMSC). Сервер может в потоковом режиме передавать данные от различных поставщиков контента с использованием одинакового MSK, и, как отмечалось выше, в случае местных рекламных интервалов в рамках одной услуги поток может содержать либо "национальный", либо "локальный", либо и тот и другой контент.

[0023] Затем BMSC собирает данные, шифрует MTK с использованием MSK и назначает сообщению идентификатор MTK_ID. Таким образом, BMSC представляет собой объект, который хранит идентификаторы MTK_ID в порядке возрастания. Если MSK специфичен для сервера, то такой "возврат" в множестве MTK_ID не выполнялся бы. Вместо этого, при перемещении к этому серверу потребовался бы новый MSK, получаемый с использованием обычного процесса извлечения MSK. Если MSK не специфичен для сервера, то потребовался бы "возврат" в пределах множества MTK_ID, и, кроме того, возникла бы проблема при извлечении MSK, поскольку MUK в любом случае специфичен для сервера.

[0024] Теперь рассмотрим процесс предоставления MBMS с точки зрения пользователя, перемещающегося между потоковыми серверами (BMSC) для непрерывного приема одной и той же услуги MBMS (которая, как упоминалось выше, может содержать различный локальный контент для рекламных интервалов). Пользователь имеет доступ к специфичному для сервера MSK, но, как следует из вышесказанного и проиллюстрированного на фиг. 1, ключ услуги MBMS/MSK специфичен для сервера, но НЕ для пользователя. Он специфичен для конкретного сервера MBMS, однако данный пользователь получает ту же услугу MBMS из множества различных серверов, выполняющих функции этой услуги (одинаковый национальный контент). MSK на различных BMSC отличаются, и поэтому пользователь получает ту же услугу MBMS из множества серверов, каждый из которых использует собственный MSK. MSK используется для защиты при передаче MTK (ключ трафика MBMS) в пользовательское оконечное устройство. Именно MTK используется для фактического шифрования контента, который в потоковом режиме передается из различных BMSC, и, согласно приведенному выше примеру, при использовании CNN® в качестве поставщика контента именно CNN® использует MTK для шифрования контента.

[0025] Суммируя приведенную выше информацию, следует отметить, что MTK специфичны для контента и для заданной услуги MBMS они могут быть одинаковы для всех серверов, однако MSK должны быть специфичны для серверов. Различные серверы, предоставляющие в потоковом режиме одинаковую услугу MBMS, могут в случае локального контента использовать различные MTK, и MSK, который защищает передачу соответствующего MTK, должен отличаться для различных BMSC. Подобные рассуждения верны и для BCAST, поскольку TEK для BCAST аналогичен MTK для MBMS, и SEK/PEK для BCAST аналогичен MSK для MBMS.

[0026] С точки зрения пользователя, принадлежащее ему устройство принимает зашифрованный контент и проверяет, из какого сервера BMSC поступил этот поток, затем выбирает корректный MSK для дешифрования MTK, после чего дешифрует контент. Согласно приведенному выше сценарию, в котором поставщик контента шифрует этот контент с помощью MTK, следует, что существует несколько "записей" (групп данных в UICC или в терминале), специфичных для сервера. Например, в карте UICC (обычно называемой смарт-картой, представляющей собой SIM-модуль идентификации абонента нового поколения в пользовательском устройстве/смартфоне) одна запись должна представлять собой один набор данных (MTK_ID, MTK_ID, ключи и связанные с ключом данные) для сервера MBMS. MBMS может быть реализована на стороне пользовательского устройства только посредством пользовательского оконечного устройства или также с помощью пользовательского оконечного устройства, функционирующего совместно с UICC/смарт-картой.

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

[0028] Однако, если пользовательское устройство перемещается между серверами и срок действия MTK истек, пользователь не обладает MSK для нового сервера, в зону которого он перемещается. В этом случае пользователь запрашивает обновление MSK. Согласно текущей спецификации в этом случае пользователь должен обратиться к BMSC, однако проблема состоит в том, что заданный индивидуально для пользователя ключ, применяемый для авторизации (MUK, пользовательский ключ MBMS), специфичен для сервера и содержит имя сервера в качестве параметра формирования ключа. Таким образом, в этом случае мобильность пользовательского устройства приводит к отказу при авторизации. Согласно примеру осуществления идей настоящего изобретения, пользовательское оконечное устройство предварительно на основе MTK_ID обращает внимание на то, что BMSC должен измениться (пользовательское оконечное устройство может по MTK_ID определить, что сообщение приходит из другого сервера), и заранее предпринимает описанные ниже меры для обновления ключей и формирования нового MSK во избежание прерывания услуги MBMS. Кроме того, если срок действия MSK истекает, пользовательское оконечное устройство может предпринять такие же меры.

[0029] В соответствии с примерами осуществления идей настоящего изобретения, если пользовательское оконечное устройство перемещается от старого первого сервера/BMSC к новому второму серверу/BMSC для поддержки текущей услуги MBMS, и срок действия MSK истек либо должен истечь в ближайшее время, пользовательское устройство автоматически выполняет новый запуск начальной загрузки для нового сервера с целью получения нового MUK. Со стороны сервера новый сервер/BMSC устанавливает связь с серверной функцией начальной загрузки (bootstrapping server function, BSF) с целью предоставления новых ключей для этого пользователя. В альтернативном варианте новый сервер/BMSC формирует из общего ключа сеанса GBA (Ks) новый заданный индивидуально для сервера ключ MUK, однако эта альтернатива предполагает, что ключ Ks действителен в течение достаточно длительного периода. В любом случае, если затем в пользовательском оконечном устройстве генерируются ключи MRK и MUK, пользовательское оконечное устройство выполняет запрос обновления нового MSK, как это в настоящее время определено для MBMS. В услуге BCAST в результате нового запуска начальной загрузки генерируется SEK и РЕK подобно новому MSK в MBMS, а также новые SMK и REK подобно новому MUK в MBMS.

[0030] Если срок действия MSK истекает или уже истек, и пользователь затем желает применять услугу (например, услуга не использовалась в период мобильности, или события мобильности и истечения MTK возникли примерно в один и тот же момент времени), сеть MBMS не осведомлена, каким BMSC обслуживается пользовательское оконечное устройство. В связи с этим пользовательское оконечное устройство запускает процедуру обновления. Существуют два способа выполнения такой процедуры пользовательским оконечным устройством.

[0031] В отсутствие мобильности пользовательское оконечное устройство обслуживается тем же сервером, поэтому истекающий или истекший MSK обрабатывается тем же сервером. В этом случае могут использоваться традиционные процедуры обновления MBMS.

[0032] В сценарии, предполагающем мобильность, в котором пользовательское оконечное устройство перемещается от старого первого сервера к новому второму серверу и срок действия MSK для услуги MBMS истек или скоро должен истечь, новый MSK для той же услуги MBMS должен поступать от нового второго сервера. Если терминал уже содержит MUK, подлежащий использованию с этим новым вторым сервером, то пользовательское оконечное устройство может инициировать обновление MSK в соответствии со стандартной спецификацией 3GPP TS33.246, но с новым вторым сервером. Следует отметить, что в любой заданный момент времени пользовательское оконечное устройство может содержать несколько MUK, которые могут храниться в упомянутых выше записях. При обновлении MSK осуществляется двухточечный обмен сообщениями, это означает, что в результате выполнения процедуры обновления MSK пользовательское оконечное устройство получает новый MSK для каждого имеющегося MUK.

[0033] Однако в том случае, если пользовательское оконечное устройство не содержит MUK для этого нового второго сервера, и срок действия MSK истекает или истек, пользовательскому оконечному устройству требуется запустить процедуру начальной загрузки.

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

[0035] В отличие от текущих реализаций, в которых смарт-карта содержит только один набор данных только для одного сервера MBMS, в соответствии с идеями настоящего изобретения пользовательское оконечное устройство должно содержать два или более MSK, которые принадлежат одной и той же услуге MBMS. Пользовательское устройство может хранить эти связанные данные в группе, так чтобы терминал был осведомлен о том, что эти данные должны обновляться. В другом варианте осуществления пользовательское оконечное устройство может хранить только информацию о времени истечения срока действия ключа и заранее обновлять различные MSK для заданной услуги MBMS.

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

[0037] Некоторые из описанных выше вариантов осуществления настоящего изобретения с точки зрения пользовательского оконечного устройства 108 обзорно показаны на фиг. 3. На фиг. 3 представлены шаги выполнения способа, соответствующие примеру осуществления настоящего изобретения, действия, осуществляемые в результате исполнения процессором программных инструкций, хранимых в памяти, или функциональные шаги, предпринимаемые устройством, таким как пользовательское оконечное устройство 108, показанное на фиг. 2 и 4. Так, например, если имеется устройство, содержащее по меньшей мере один процессор и по меньшей мере один модуль памяти, в которой хранится программа, состоящая из машиночитаемых инструкций, например устройство, показанное на фиг. 4, то по меньшей мере один модуль памяти и машиночитаемые инструкции могут быть сконфигурированы таким образом, чтобы при взаимодействии по меньшей мере с одним процессором устройство выполняло по меньшей мере шаги, показанные на фиг. 3.

[0038] Более конкретно, на фиг. 3 показано, что на шаге 302 пользовательское оконечное устройство активизирует нового поставщика услуги MBMS/BCAST, к которому оно перемещается при приеме данных услуги MBMS/BCAST (второй сервер/BMSC 106, показанный на фиг. 2), для генерации новых заданных индивидуально для пользователя ключей защиты (MUK и MRK для MBMS или SMK/REK и SI для BCAST). В приведенном выше примере пользовательское оконечное устройство выполняет эту операцию путем запуска процедуры начальной загрузки GBA. Затем на шаге 304 оконечное устройство принимает от нового поставщика услуги MBMS/BCAST новый ключ защиты, заданный индивидуально для нового поставщика услуги (новый MSK для MBMS или новый SEK/PEK для BCAST). Пользовательское оконечное устройство также на шаге 305 генерирует новые заданные индивидуально для пользователя ключи защиты для потокового сервера перед или после приема на шаге 304 заданного индивидуально для сервера ключа защиты. На дополнительном шаге 306 пользовательское оконечное устройство также принимает от нового поставщика услуги MBMS/BCAST сообщение с новым общим ключом сеанса (ключ GBA Ks). Наконец, на шаге 308 пользовательское оконечное устройство использует новый сгенерированный им заданный индивидуально для пользователя ключ защиты (новый MSK или SEK/PEK, который пользовательское оконечное устройство сгенерировало на шаге 305, а также новый ключ защиты, полученный оконечным устройством на шаге 304) с новым поставщиком услуги MBMS/BCAST для ранее установленной услуги MBMS/BCAST. В общем случае сервер MBMS/BCAST и услуга MBMS/BCAST могут обозначаться как потоковый сервер и потоковая услуга. Шаги, показанные на фиг. 3, могут выполняться пользовательским оконечным устройством автоматически в случае обнаружения того, что истекает или близок к истечению срок действия старого ключа защиты, заданного индивидуально для старого поставщика потоковой услуги (MSK/SEK/PEK старого/первого сервера 104 MBMS/BCAST), который ранее предоставлял потоковую услугу пользовательскому оконечному устройству 108.

[0039] Выше отмечалась возможность добавления локального контента к национальному или общему контенту для услуги MBMS/BCAST, что может привести к различиям в том, что касается применения ключей MTK/TEK различными BMSC. На фиг. 2 показано, что в соответствии с вариантом осуществления идей настоящего изобретения объем применения MTK/TEK может контролироваться централизованно на централизованном сервере 102 контента, который предоставляет услугу. Этот сервер 102 шифрует контент MBMS/BCAST с использованием достоверного MTK и направляет его в потоковые серверы 104, 106. В этих вариантах осуществления настоящего изобретения централизованный сервер 102 контента хранит основную запись для потребления MTK/TEK из всех подключенных BMSC 104, 106. С этой целью для удобства доступные MTK/TEK и соответствующие им идентификаторы (MTK_ID или TEKJD) могут разделяться на две области или пула, одна область или пул зарезервирована для глобального/национального контента, а другая область или пул зарезервирована для локального контента. В рамках одной услуги MBMS могут одновременно обрабатываться множество MTK, поэтому для заданной услуги MBMS несложно поддерживать один MTK для национального/общего контента, а другие MTK - для локального контента. Подобная стратегия со множеством TEK может использоваться и в BCAST. Таким образом, могут быть зарезервированы диапазоны MTK_ID/TEKJD для национального и локального контента.

[0040] В этом случае, если некоторые потоковые серверы содержат локальный контент, они применяют для локального контента большее количество MTK, а также MTK_ID, что справедливо и для TEK в BCAST. Так, например, один потоковый сервер, содержащий локальный контент для Калифорнии, может потреблять 35 MTK и MTK_ID для локального контента, который он включает в заданную услугу MBMS, в то время как другой потоковый сервер во Флориде может потреблять 50 MTK и MTK_ID для локального контента, который он включает в ту же услугу MBMS.

[0041] Согласно одному из вариантов осуществления настоящего изобретения серверы BMSC возвращают в централизованный сервер 102 контента информацию о количестве MTK_ID, потребляемых для локального контента заданной потоковой услуги MBMS (или сообщают о количестве TEKJD для заданной потоковой услуги BCAST); например, BMSC #1 использовал ху MTK_ID. Благодаря этой обратной связи централизованный сервер 102 контента может отслеживать использованные MTK_ID и затем соответственно устанавливать следующий больший MTK_ID, подлежащий использованию. Следует отметить, что даже если MTK используется централизованным сервером контента, MTK_ID все еще может назначаться в серверах BMSC.

[0042] Согласно одному из вариантов осуществления настоящего изобретения, BMSC использует централизованный сервер для формирования временной отметки, применяемой в качестве MTK_ID. Если этот централизованный сервер представляет собой сервер NTP-UTC (Network Time Protocol-Universal Time Coordinated, протокол сетевого времени - всемирного координированного времени), то идентификаторы MTK_ID остаются синхронизированными между различными BMSC, и с точки зрения MTK_ID при переключении между различными BMSC рассогласования не наблюдается. Поскольку все BMSC используют одинаковый MSK, устройство 108 способно дешифровать поток, поступающий из BMSC. Как описывалось выше, MUK, используемый для дешифрования MSK, специфичен для сервера, поэтому в случае обновления MSK должен генерироваться новый MUK. Это в значительной степени неудобно, поскольку период действия MSK может составлять от нескольких дней до нескольких месяцев.

[0043] Согласно другому варианту осуществления, серверы BMSC запрашивают блоки MTK для своего локального использования. Централизованный сервер 102 контента затем выбирает блок MTK для заданной услуги MBMS и информирует отдельные запрашивающие BMSC о том, какие MTK_ID доступны для шифруемого локального контента.

[0044] Согласно еще одному варианту осуществления настоящего изобретения, централизованный сервер 102 контента только предоставляет отдельным серверам 104, 106 BMSC сообщение, содержащее MTK, который может использоваться этим BMSC для локального контента. Этот MTK шифруется с использованием MSK из данного BMSC в этом сообщении, поступающем из централизованного сервера 102 контента. Если BMSC 104, 106 затем добавляют MTK_ID, который указывает терминалу, какой MSK подлежит использованию, то отпадает какая-либо необходимость в предоставлении централизованным сервером 102 контента блока зарезервированных MTK_ID, о которых шла речь выше. Любой из описанных выше способов управления ключами MTK для национального и локального контента может подобным образом применяться в системе BCAST для ключей TEK и идентификаторов TEK_ID.

[0045] Альтернативное предложение, заключающееся в использовании скользящего окна с фиксированным количеством MTK_ID (в котором также могут записываться ключи шифрования трафика), является неудовлетворительным для целей локального контента, поскольку предлагаемый размер недостаточно большой для локального контента, соответствующего всем потенциально различным локальным рекламным рынкам. Кроме того, возможность использования локального контента существенно увеличивает "разр