способ передачи/приема информации шифрования в мобильной системе вещания и система для такового
Классы МПК: | H04W12/04 распределение ключей H04L9/28 с использованием специального алгоритма шифрования |
Автор(ы): | ХВАНГ Сунг-Ох (KR), ЛИ Биунг-Рае (KR), ЛИ Коок-Хеуи (KR), ДЗУНГ Бо-Сун (KR), ЛИ Дзонг-Хио (KR), ОХ Дзае-Квон (KR), ЛИ Дзае-Йонг (KR) |
Патентообладатель(и): | САМСУНГ ЭЛЕКТРОНИКС КО., ЛТД. (KR) |
Приоритеты: |
подача заявки:
2006-11-10 публикация патента:
27.04.2010 |
Изобретение относится к способу и устройству шифрования в мобильной системе вещания. Техническим результатом является повышение эффективности шифрования передаваемого контента. Технический результат достигается тем, что в мобильной системе вещания управление (BSM) подпиской службы BCAST управляет абонентской информацией терминала, и передает на распространение/адаптацию (BSD/A) услуги службы BCAST первое сообщение доставки, включающее в состав материал (RKM) ключа регистрации, предусмотренный для регистрация услуги вещания для терминала, и включающее в состав, по меньшей мере, один идентификатор услуги или контента. BSD/A передает на BSM первое сообщение подтверждения доставки, включающее в состав информацию, указывающую успех/неудачу в приеме первого сообщения доставки, и передает RKM на терминал. 5 н. и 16 з.п. ф-лы, 18 ил., 7 табл.
Формула изобретения
1. Способ передачи/приема информации шифрования в системе мобильного радиовещания, поддерживающей службу радиовещания (BCAST), при этом способ содержит этапы, на которых:
посредством службы распространения/адаптации (BSD/A) службы радиовещания (BCAST) передают на BCAST управление подпиской (BSM), предусмотренное для управления абонентской информацией терминала, первое сообщение запроса, включающее в себя, по меньшей мере, одно из идентификатора службы и идентификатора контента и запрашивающее доставку материала ключа регистрации (RKM) для регистрации службы радиовещания терминала; и
передают посредством BSM на BSD/A первое сообщение ответа на запрос, включающее в себя RKM, после приема первого сообщения запроса.
2. Способ по п.1, дополнительно содержащий этапы, на которых:
передают на BSM посредством BSD/A второе сообщение запроса, включающее в себя, по меньшей мере, одно из идентификатора службы и идентификатора контента и запрашивающее доставку сообщения долгосрочного ключа (LKM), предоставленного на терминал во время подписки на услугу радиовещания; и
передают на BSD/A посредством BSM второе сообщение ответа на запрос, включающее в себя LKM, после приема второго сообщения запроса.
3. Способ по п.2, дополнительно содержащий этапы, на которых:
передают на BSM посредством BSD/A третье сообщение запроса, включающее в себя, по меньшей мере, одно из идентификатора службы и идентификатора контента и запрашивающее доставку сообщения краткосрочного ключа (SKM), включающего в себя ключ шифрования трафика (ТЕК), используемый для расшифровывания терминалом службы радиовещания; и
передают на BSD/A посредством BSM третье сообщение ответа на запрос, включающее в себя SKM, после приема третьего сообщения запроса.
4. Способ по п.3, в котором каждое из сообщений запроса от первого до третьего содержит поля, определенные в нижеследующей таблице:
метка | Тип сообщения | Применяемый формат сообщения | Информация доставки |
1 | Сообщение запроса ТЕК | Req-1 | ТЕК |
2 | Сообщение ответа на запрос ТЕК | Res-1 или Res-2 | |
3 | Сообщение доставки ТЕК | Tra-1 | |
4 | Сообщение подтверждения доставки ТЕК | Con-1 или Con-2 | |
5 | Сообщение запроса SKM | Req-1 | SKM |
6 | Сообщение ответа на запрос SKM | Res-1 или Res-2 | |
7 | Сообщение доставки SKM | Tra-1 | |
8 | Сообщение подтверждения доставки SKM | Con-1 или Con-2 | |
9 | Сообщение запроса LKM | Req-1 | LKM |
10 | Сообщение ответа на запрос LKM | Res-1 или Res-2 | |
11 | Сообщение доставки LKM | Tra-1 | |
12 | Сообщение подтверждения доставки LKM | Con-1 или Con-2 | |
13 | Сообщение запроса RKM | Req-1 | RKM |
14 | Сообщение ответа на запрос RKM | Res-1 или Res-2 | |
15 | Сообщение доставки RKM | Tra-1 | |
16 | Сообщение подтверждения доставки RKM | Con-1 или Con-2 |
5. Способ по п.3, в котором каждое из сообщений ответа на запрос от первого до третьего сообщения содержит поля, определенные в нижеследующей таблице:
Название | Тип | Категория | Количество элементов | Описание | Тип данных |
Tag | E | M | 1 | Тип сообщения | Integer |
Version | E | O | 1 | Версия стандарта, поддерживаемого данные сообщением | Integer |
Message | E | M | 1 | Идентификатор | String |
ID | сообщения запроса | ||||
Destinatior | E | M | 1 | Идентификатор | String |
получателя сообщения | |||||
Source | E | M | 1 | Идентификатор источника | String |
сообщения | |||||
Service/Content Info. | E | O | 1 | Связанная информация, такая как идентификатор службы/контента | String |
Status | E | M | 1 | Результат ответа на сообщение | Integer |
Data | E | O | 1 | Информация, планируемая для доставки получателю | Binary |
Time | E | O | 1 | Время, в которое доставлено сообщение | String |
6. Способ передачи/приема информации шифрования в системе мобильного радиовещания, поддерживающей службу радиовещания (BCAST), при этом способ содержит этапы, на которых:
передают на BCAST службу распространения/адаптации (BSD/A) посредством BCAST управления подпиской (BSM) первое сообщение доставки, содержащее, по меньшей мере, одно из идентификатора службы и идентификатора контента и включающее в себя материал ключа регистрации (RKM) для регистрации абонента терминала; и
передают на BSM посредством BSD/A первое сообщение подтверждения доставки, включающее в себя информацию, указывающую успех/неудачу в приеме первого сообщения доставки.
7. Способ по п.6, дополнительно содержащий этапы, на которых:
передают на BSD/A посредством BSM второе сообщение доставки, включающее в себя, по меньшей мере, одно из идентификатора службы и идентификатора контента и включающее в себя сообщение долгосрочного ключа (LKM), предоставленное на терминал во время подписки на службу радиовещания; и
передают на BSM посредством BSD/A второе сообщение подтверждения доставки, включающее в себя информацию, указывающую успех/неудачу в приеме второго сообщения доставки.
8. Способ по п.7, дополнительно содержащий этапы, на которых:
передают на BSD/A посредством BSM третье сообщение доставки, включающее в себя, по меньшей мере, одно из идентификатора службы и идентификатора контента и включающее в себя сообщение краткосрочного ключа (SKM), включающее в себя ключ шифрования трафика (ТЕК), используемый для расшифровывания терминалом службы радиовещания; и
передают на BSM посредством BSD/A третье сообщение подтверждения доставки, включающее в себя информацию, указывающую успех/неудачу в приеме третьего сообщения доставки.
9. Способ по п.8, в котором каждое из сообщений доставки от первого до третьего содержит поля, определенные в нижеследующей таблице:
Название | Тип | Категория | Количество элементов | Описание | Тип данных |
Tag | E | M | 1 | Тип сообщения | Integer |
Version | E | O | 1 | Версия стандарта, поддерживаемого данным сообщением | Integer |
Target Terminal | E | M | 1 | Целевой терминал для этого сообщения | String |
Message ID | E | M | 1 | Идентификатор данного сообщения | String |
Destination | E | M | 1 | Идентификатор получателя сообщения | String |
Source | E | M | 1 | Идентификатор | String |
источника сообщения | |||||
Service/Content Info | E | M | 1 | Связанная информация, такая как идентификатор службы/контента | String |
Data | E | M | 1 | Информация, планируемая для доставки получателю | Binary |
Time | E | O | 1 | Время, в которое доставлено сообщение | String |
10. Способ по п.8, в котором каждое из сообщений подтверждения доставки от первого до третьего сообщения содержит поля, определенные в нижеследующей таблице:
Название | Тип | Категория | Количество элементов | Описание | Тип данных |
Tag | Е | М | 1 | Тип сообщения | Integer |
Version | Е | O | 1 | Версия стандарта, поддерживаемого данным сообщением | Integer |
Message ID | E | M | 1 | Идентификатор сообщения доставки | String |
Destination | E | M | 1 | Идентификатор получателя сообщения | String |
Source | E | M | 1 | Идентификатор источника сообщения | String |
Service/Conter tInfo. | E | O | 1 | Связанная информация, такая как идентификатор службы/контента | String |
Status | E | M | 1 | Результат подтверждения сообщения | Integer |
Time | E | O | 1 | Время, в которое доставлено сообщение | String |
11. Система мобильного радиовещания, поддерживающая службу радиовещания (BCAST), содержащая:
BCAST управление подпиской (BSM) для управления абонентской информацией терминала, и для передачи на BCAST службу распространения/адаптации (BSD/A) первого сообщения доставки, включающего в себя материал ключа регистрации (RKM), предусмотренный для регистрации службы радиовещания терминала, и включающего в себя, по меньшей мере, одно из идентификатора службы и идентификатора контента; и
BSD/A для передачи на BSM первого сообщения подтверждения доставки, включающего в себя информацию, указывающую успех/неудачу в приеме первого сообщения доставки, и для передачи RKM на терминал.
12. Система мобильного радиовещания по п.11, в которой BSM передает на BSD/A второе сообщение доставки, включающее в себя сообщение долгосрочного ключа (LKM), предоставленное на терминал во время подписки на службу радиовещания, и включающее также, по меньшей мере, одно из идентификатора службы и идентификатора контента; и
при этом BSD/A передает на BSM второе сообщение подтверждения доставки, включающее в себя информацию, указывающую успех/неудачу в приеме второго сообщения доставки, и передает LKM на терминал.
13. Система мобильного радиовещания по п.12, в которой BSM передает на BSD/A третье сообщение доставки, включающее в себя сообщение краткосрочного ключа (SKM), включающее в себя ключ шифрования трафика (ТЕК), используемый для расшифровывания терминалом службы радиовещания, и включающее также, по меньшей мере, одно из идентификатора службы и идентификатора контента; и
при этом BSD/A передает на BSM третье сообщение подтверждения доставки, включающее в себя информацию, указывающую успех/неудачу в приеме третьего сообщения доставки, и передает SKM на терминал.
14. Система мобильного радиовещания по п.13, в которой каждое из сообщений доставки от первого до третьего содержит поля, определенные в нижеследующей таблице:
Название | Тип | Категория | Количество элементов | Описание | Тип данных |
Tag | E | M | 1 | Тип сообщения | Integer |
Version | E | O | 1 | Версия стандарта, поддерживаемого данным сообщением | Integer |
Target Terminal | E | M | 1 | Целевой терминал для этого сообщения | String |
Message ID | E | M | 1 | Идентификатор данного сообщения | String |
Destination | E | M | 1 | Идентификатор получателя сообщения | String |
Source | E | M | 1 | Идентификатор источника сообщения | String |
Service/Content info | E | M | 1 | Связанная информация, такая как идентификатор службы/контента | String |
Data | E | M | 1 | Информация, планируемая для доставки получателю | Binary |
Time | E | O | 1 | Время, в которое доставлено сообщение | String |
15. Система мобильного радиовещания по п.13, в которой каждое из сообщений подтверждения доставки от первого до третьего содержит поля, определенные в нижеследующей таблице:
Название | Тип | Категория | Количество элементов | Описание | Тип данных |
Tag | E | M | 1 | Тип сообщения | Integer |
Version | E | O | 1 | Версия стандарта, поддерживаемого данным сообщением | Integer |
Message ID | E | M | 1 | Идентификатор сообщения доставки | String |
Destination | E | M | 1 | Идентификатор получателя сообщения | String |
Source | E | M | 1 | Идентификатор источника сообщения | String |
Service/Content info | E | O | 1 | Связанная информация типа идентификатор службы/контента | String |
Status | E | M | 1 | Результат подтверждения | Integer |
сообщения | |||||
Time | E | O | 1 | Время, в которое доставлено сообщение | String |
16. Система мобильного радиовещания, поддерживающая службу радиовещания (BCAST), содержащая:
BCAST службу распространения/адаптации (BSD/A) для передачи на BCAST управление подпиской (BSM) первого сообщения запроса, запрашивающего доставку материала ключа регистрации (RKM) для регистрации службы радиовещания терминала и включающего в себя, по меньшей мере, одно из идентификатора службы и идентификатора контента, и после приема RKM от BSM для передачи RKM на терминал; и
BSM для управления абонентской информацией терминала и передачи на BSD/A сообщения ответа на первый запрос, включающего в себя RKM, после приема первого сообщения запроса.
17. Система мобильного радиовещания по п.16, в которой BSD/A передает на BSM второе сообщение запроса, запрашивающее доставку сообщения долгосрочного ключа (LKM), предоставленного на терминал во время подписки на службу радиовещания, и включающее в себя, по меньшей мере, одно из идентификатора службы и идентификатора контента, и после приема LKM от BSM передает LKM на терминал; и
при этом после приема второго сообщения запроса BSM передает на BSD/A второе сообщение ответа на запрос, включающее в себя LKM.
18. Система мобильного радиовещания по п.17, в которой BSD/A передает на BSM третье сообщение запроса, запрашивающее доставку сообщения краткосрочного ключа (SKM), включающее в себя ключ шифрования трафика (ТЕК), используемый для расшифровывания терминалом службы радиовещания, и включающее в себя, по меньшей мере, одно из идентификатора службы и идентификатора контента, и после приема SKM от BSM передает SKM на терминал; и
при этом после приема третьего сообщения запроса BSM передает на BSD/A третье сообщение ответа на запрос, включающее в себя SKM.
19. Система мобильного радиовещания по п.17, в которой каждое из сообщений запроса от первого до третьего содержит поля, определенные в нижеследующей таблице:
Название | Тип | Категория | Количество элементов | Описание | Тип данных |
Tag | E | M | 1 | Тип сообщения | Integer |
Version | E | O | 1 | Версия стандарта, поддерживаемого этим сообщением | Integer |
Message ID | E | M | 1 | Идентификатор данного сообщения | String |
Destination | E | M | 1 | Идентификатор получателя сообщения | String |
Source | E | M | 1 | Идентификатор источника сообщения | String |
Service/Content Info | E | M | 1 | Связанная информация, такая как идентификатор службы/контента | String |
Time | E | O | 1 | Время, когда доставлено сообщение | String |
20. Система мобильного радиовещания по п.17, в которой каждое из сообщений ответа на запрос от первого до третьего содержит поля, определенные в нижеследующей таблице:
Название | Тип | Категория | Количество элементов | Описание | Тип данных |
Tag | E | M | 1 | Тип сообщения | Integer |
Version | E | O | 1 | Версия стандарта, поддерживаемого данным сообщением | Integer |
Message ID | E | M | 1 | Идентификатор сообщения запроса | String |
Destination | E | M | 1 | Идентификатор получателя сообщения | String |
Source | E | M | 1 | Идентификатор источника сообщения | String |
Service/Content Info. | E | O | 1 | Связанная информация, такая как идентификатор службы/контента | String |
Status | E | M | 1 | Результат ответа на сообщение | Integer |
Data | E | O | 1 | Информация, планируемая для доставки получателю | Binary |
Time | E | O | 1 | Время, в которое доставлено сообщение | String |
21. Способ передачи/приема информации шифрования в системе мобильного радиовещания, поддерживающей службу радиовещания (BCAST), при этом способ содержит этапы, на которых:
передают посредством службы распространения/адаптации (BSD/A), службы радиовещания (BCAST) на BCAST управление подпиской (BSM), предусмотренное для управления абонентской информацией терминала, первое сообщение запроса, включающее в себя, по меньшей мере, одно из идентификатора службы и идентификатора контента, и запрашивающее доставку материала ключа регистрации (RKM), предназначенного для регистрации службы радиовещания для терминала;
передают на BSD/A посредством BSM первое сообщение ответа на запрос, включающее в себя RKM, после приема первого сообщения запроса;
передают на BSM посредством BSD/A второе сообщение запроса, включающее в себя, по меньшей мере, одно из идентификатора службы и идентификатора контента и запрашивающее доставку сообщения долгосрочного ключа (LKM), предоставленного на терминал во время подписки на службу радиовещания;
передают на BSD/A посредством BSM второе сообщение ответа на запрос, включающее в себя LKM, после приема второго сообщения запроса;
передают на BSM посредством BSD/A третье сообщение запроса, включающее в себя, по меньшей мере, одно из идентификатора службы и идентификатора контента и запрашивающее доставку сообщения краткосрочного ключа (SKM), включающего в себя ключ шифрования трафика (ТЕК), используемый для расшифровывания терминалом службы радиовещания;
передают на BSD/A посредством BSM третье сообщение ответа на запрос, включающее в состав SKM, после приема третьего сообщения запроса; и
посредством терминала извлекают ТЕК из SKM с использованием RKM и LKM после приема RKM, LKM и SKM.
Описание изобретения к патенту
2420-150765RU/016
СПОСОБ ПЕРЕДАЧИ/ПРИЕМА ИНФОРМАЦИИ ШИФРОВАНИЯ
В МОБИЛЬНОЙ СИСТЕМЕ ВЕЩАНИЯ И СИСТЕМА ДЛЯ ТАКОВОГО
ОПИСАНИЕ
ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
Настоящее изобретение, в целом, относится к способу и устройству шифрования в мобильной системе вещания. Более конкретно, настоящее изобретение относится к способу для передачи/приема информации шифрования, предназначенному для защиты услуги/контента в мобильной системе вещания, и к системе для такового.
УРОВЕНЬ ТЕХНИКИ
В целом, служба вещания (BCAST) относится к техническому решению, в котором сервер, управляющий службой вещания, транслирует зашифрованную услугу и многие терминалы принимают зашифрованную услугу вещания. Каждый из терминалов расшифровывает зашифрованную услугу, поставленную от сервера, используя свой собственный ключ шифрования, таким образом предоставляя пользователю возможность пользоваться соответствующей услугой.
Услуга службы BCAST может быть платной услугой. Чтобы удовлетворять требованию технологии охраны авторского права для предотвращения незаконного копирования и распространения услуги, Проект (3 GPP) партнерства систем связи 3-го поколения или Открытый союз (OMA) по мобильной связи, который является группой разработки стандартов, предложил технологию управления (DRM) правами на цифровые материалы, которая основана на приспособляемости и средстве, предназначенного для Right Object (RO, объект прав) пользователя. Однако мобильная система вещания не дает определения способа шифрования, предназначенного для защиты услуги между объектами, и интерфейсов между объектами, так что имеется потребность дать определение способа шифрования.
Соответственно, имеется потребность в усовершенствованных устройстве и способе для передачи/приема информации шифрования в мобильной системе вещания.
РАСКРЫТИЕ ИЗОБРЕТЕНИЯ
Примерные варианты осуществления настоящего изобретения адресованы, по меньшей мере, вышеупомянутым трудностям и/или недостаткам и обеспечивают, по меньшей мере, описанные ниже преимущества. Соответственно, аспект настоящего изобретения должен обеспечивать способ передачи/приема информации шифрования между объектами в мобильной системе вещания и систему для такового.
Согласно одному примерному аспекту настоящего изобретения обеспечивается способ передачи/приема информации шифрования в мобильной системе вещания, поддерживающей службу вещания (BCAST, broadcast), в котором мобильная система вещания включает в себя Управление подпиской службы BCAST(BCAST Subscription Manager, сокращенно BSM), чтобы управлять абонентской информацией терминала и формировать ключ шифрования, с помощью которого терминал расшифровывает, по меньшей мере, одну зашифрованную услугу или контент, и Распространение/адаптацию (BCAST Service Distribution/ Adaptation, сокращенно BSD/A) услуги службы BCAST, чтобы передавать ключ шифрования. Способ содержит этапы передачи посредством BSD/A на BSM первого сообщения запроса, включающего в себя, по меньшей мере, один идентификатор услуги или контента, и запрашивающего доставку материала (Registration Key Material, сокращенно RKM) ключа регистрации, предназначенного для регистрации услуги вещания для терминала, и после приема первого сообщения запроса, осуществления передачи посредством BSM на BSD/A сообщения ответа на первый запрос, включающего в состав RKM.
В одном примерном варианте осуществления способ дополнительно содержит этапы передачи посредством BSD/A на BSM второго сообщения запроса, включающего в себя, по меньшей мере, один идентификатор услуги или контента, и запрашивающего доставку сообщения долгосрочного ключа (Long-Term Key Message, сокращенно LKM), поставленного на терминал в течение подписки на услугу вещания, и после приема второго сообщения запроса, осуществления посредством BSM передачи на BSD/A сообщения ответа на второй запрос, включающего в состав LKM.
В одном примерном варианте осуществления способ дополнительно содержит этапы передачи посредством BSD/A на BSM третьего сообщения запроса, включающего в состав, по меньшей мере, один идентификатор услуги или контента, и запрашивающего доставку Сообщения (SKM) краткосрочного ключа, включающего в состав Ключ (TEK) шифрования трафика, используемый терминалом для расшифровывания конкретной услуги вещания, и после приема третьего сообщения запроса BSM осуществляет передачу на BSD/A сообщения ответа на третий запрос, включающего в состав SKM.
Согласно другому примерному аспекту настоящего изобретения обеспечивается способ передачи/приема информации шифрования в мобильной системе вещания, поддерживающей службу (BCAST) вещания, в котором мобильная система вещания включает в себя Управление (BSM) подпиской службы BCAST для управления абонентской информацией терминала и формировать ключ шифрования, с помощью которого терминал расшифровывает, по меньшей мере, одну зашифрованную услугу или контент, и Распространение/адаптацию (BSD/A) услуги службы BCAST, чтобы передавать ключ шифрования. Способ содержит стадию передачи посредством BSM на BSD/A первого сообщения доставки, включающего в состав, по меньшей мере, один идентификатор услуги или контента, и включающего материал (RKM) ключа регистрации, предназначенный для регистрации услуги вещания для терминала, и BSD/A осуществляет передачу на BSM первого сообщения подтверждения доставки, включающего в состав информацию, указывающую успех/неудачу в приеме первого сообщения доставки.
В примерном варианте осуществления способ дополнительно включает в себя этапы передачи посредством BSM на BSD/A второго сообщения доставки, включающего в состав, по меньшей мере, один идентификатор услуги или контента, и включающего сообщение (LKM) долгосрочного ключа, поставленного на терминал в течение подписки на услугу вещания, и осуществления посредством BSD/A передачи на BSM второго сообщения подтверждения доставки, включающего в состав информацию, указывающую успех/неудачу в приеме второго сообщения доставки.
В примерном варианте осуществления способ дополнительно содержит стадию передачи посредством BSM на BSD/A третьего сообщения доставки, включающего в состав, по меньшей мере, один идентификатор услуги или контента, и включающего сообщение (SKM) краткосрочного ключа, включающего ключ шифрования трафика (TEK), используемый терминалом для расшифровывания услуги вещания, и BSD/A передает на BSM сообщение подтверждения третьей доставки, включающее информацию, указывающую успех/неудачу в приеме третьего сообщения доставки.
Согласно дополнительно еще одному примерному аспекту настоящего изобретения обеспечивается мобильная система вещания, поддерживающая службу вещания (BCAST). Примерная мобильная система вещания включает в себя управление подпиской (BSM) службы BCAST, чтобы управлять абонентской информацией терминала, и для передачи на распространение/адаптацию (BSD/A) услуги BCAST первое сообщение доставки, включающее материал ключа регистрации (RKM), предусмотренный для регистрация услуги вещания терминала и включающего в состав, по меньшей мере, один идентификатор или услуги, или контента; и BSD/A для передачи на BSM сообщение подтверждения первой доставки, включает информацию, указывающую успех/неудачу в приеме первого сообщения доставки, и передает RKM на терминал.
В примерном варианте осуществления BSM передает на BSD/A второе сообщение доставки, включающее Сообщение долгосрочного ключа (LKM), поставленное на терминал в течение подписки на конкретную услуги вещания и включающее также в состав, по меньшей мере, один идентификатор или услуги, или контента; и BSD/A передает на BSM второе сообщение подтверждения доставки, включающее в состав информацию, указывающую успех/неудачу в приеме второго сообщения доставки, и передает LKM на терминал.
В примерном варианте осуществления BSM передает на BSD/A третье сообщение доставки, включающее в состав Сообщение (SKM) краткосрочного ключа, включающее в состав Ключ (TEK) шифрования трафика, используемый терминалом для расшифровывания услуги вещания, и включающее также, по меньшей мере, один идентификатор услуги или контента; и BSD/A передает на BSM третьей сообщение подтверждения доставки, включающее в состав информацию, указывающую успех/неудачу в приеме третьего сообщения доставки, и передает SKM на терминал.
Согласно следующему примерному аспекту настоящего изобретения обеспечивается мобильная система вещания, поддерживающая службу (BCAST) вещания. Примерная мобильная система вещания включает в себя Распространение/адаптацию (BSD/A) услуги службы BCAST, чтобы передавать на Управление (BSM) подпиской службы BCAST первое сообщение запроса, запрашивающее доставку Материала (RKM) ключа регистрации, предназначенного для регистрации услуги вещания терминала, и включающего в состав, по меньшей мере, один идентификатор услуги или контента, и после приема RKM от BSM, передавать RKM на терминал и BSM для осуществления управления абонентской информацией терминала, и после приема первого сообщения запроса, передавать на BSD/A сообщение ответа на первый запрос, включающее RKM.
В примерном варианте осуществления BSD/A передает на BSM второе сообщение запроса, запрашивающее доставку Сообщения (LKM) долгосрочного ключа, поставленного на терминал в течение подписки на услугу вещания и включающего в состав, по меньшей мере, один идентификатор услуги или контента, и после приема LKM от BSM, передает LKM на терминал и после приема второго сообщения запроса BSM передает на BSD/A второе сообщение ответа запроса, включающее LKM.
В примерном варианте осуществления BSD/A передает на BSM третье сообщение запроса, запрашивающее доставку сообщения (SKM) краткосрочного ключа, включающее в состав Ключ (TEK) шифрования трафика, используемый терминалом для расшифровывания услуги вещания, и включающее в состав, по меньшей мере, один идентификатор услуги или контента, и после приема SKM от BSM, передает SKM на терминал и после приема третьего сообщения запроса BSM передает на BSD/A третье сообщение ответа запроса, включающее в состав SKM.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Вышеупомянутые и другие задачи, признаки и преимущества настоящего изобретения станут более очевидными из нижеследующего подробного описания, рассматриваемого вместе с сопроводительными чертежами, на которых:
Фиг.1 - схема сигнализации, иллюстрирующая последовательность передачи сигналов относительно информации шифрования в мобильной системе вещания согласно примерному варианту осуществления настоящего изобретения;
Фиг.2A и 2B - схемы, иллюстрирующие поток информации между объектами сервера согласно примерному варианту осуществления настоящего изобретения, для Защиты услуги (Service Protection) и Защиты контента (Content Protection), соответственно;
Фиг.3A и 3B - схемы, иллюстрирующие способ обмена сообщениями между BSA и BSM для Защиты контента согласно примерному варианту осуществления настоящего изобретения;
Фиг.4 - схема, иллюстрирующая стек протоколов, составляющий интерфейс обмена информацией между BSA и BSM согласно примерному варианту осуществления настоящего изобретения;
Фиг.5A и 5B - схемы, иллюстрирующие способ получения TEK посредством BSD/A для Защиты услуги согласно примерному варианту осуществления настоящего изобретения;
Фиг.6 - схема, иллюстрирующая стек протоколов для интерфейса между BSD/A и BSM для Защиты услуги согласно примерному варианту осуществления настоящего изобретения;
Фиг.7А и 7B - схемы, иллюстрирующие способ получения SKM посредством BSD/A согласно примерному варианту осуществления настоящего изобретения;
Фиг.8А и 8B - схемы, иллюстрирующие способ получения LKM посредством BSD/A согласно примерному варианту осуществления настоящего изобретения;
Фиг.9А и 9B - схемы, иллюстрирующие способ получения RKM посредством BSD/A для Защиты услуги и Защиты контента согласно примерному варианту осуществления настоящего изобретения;
Фиг.10 - схема, иллюстрирующая стек протоколов для интерфейса между BSD/A и BSM для Защиты услуги согласно примерному варианту осуществления настоящего изобретения;
Фиг.11 - схема, иллюстрирующая стек протоколов для интерфейса между BSD/A и BSM для Защиты контента согласно примерному варианту осуществления настоящего изобретения;
Фиг.12 - схема, иллюстрирующая Терминал в мобильной системе вещания согласно примерному варианту осуществления настоящего изобретения.
По всем чертежам, одинаковые номера ссылочных позиций относятся к одинаковым элементам, функциональным возможностям и структурам.
ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ
Определенные в описании вопросы, такие как подробные конструктивные решения и элементы, представлены, чтобы помочь всестороннему пониманию вариантов осуществления изобретения и являются лишь примерными. Соответственно, средние специалисты в данной области техники признают, что могут быть выполнены различные изменения и модификации описанных в документе вариантов осуществления без выхода за рамки объема и существа изобретения. К тому же описания известных функций и конструктивных решений опущены для ясности и краткости. Примерные варианты осуществления настоящего изобретения далее будут описаны подробно со ссылкой на чертежи.
В нижеследующем подробном описании будут представлены примерные варианты осуществления настоящего изобретения для достижения вышеупомянутых и других целей. Хотя для удобства будут использоваться именования объектов, определенных в Проекте (3 GPP) партнерства систем связи 3-го поколения, который является стандартом асинхронной мобильным связи, или Открытым союзом (Open Mobile alliance, сокращенно OMA) по мобильной связи, который является стандартом по приложениям терминала, стандарты и именования не должны ограничивать объем настоящего изобретения, и настоящее изобретение может быть применимо к системам, имеющим сходные технические исходные данные.
Настоящее изобретение предлагает способ и систему, предназначенные для осуществления защиты услуги вещания. Конкретно настоящее изобретение предлагает в сети вещания структуру для защиты услуги и функцию каждого объекта. С этой целью настоящее изобретение устойчиво доставляет пересылаемую на терминал услугу в соответствии со структурой и функцией каждого объекта, включая в них терминал, таким образом позволяя терминалу воспроизводить услугу.
Примерная мобильная система вещания и поток сообщений в ней теперь будут описаны подробно со ссылкой на Фиг.1.
На Фиг.1 показана схема сигнализации, иллюстрирующая поток передачи сигналов для информации шифрования в мобильной системе вещания в соответствии с примерным вариантом осуществления настоящего изобретения.
Сначала будет описана функция каждого объекта по Фиг.1. Создание контента (Content Creation, сокращенно CC) 10 является поставщиком услуги Службы вещания (BCAST). Услуга BCAST может включать в себя услугу вещания аудио/видео, услугу загрузки по сети файла музыки/данных, и подобное.
Приложение услуги (Service Application) (BSA) 20 службы BCAST обрабатывает данные услуги BCAST, поставленные от Создания контента 10 в формате, соответствующем сети (с поддержкой) BCAST, формирует данные услуги BCAST, и формирует стандартизированные метаданные, необходимые для руководства мобильного вещания.
Распространение/адаптация услуги (BSD/A) 30 службы BCAST устанавливает средство связи, через которое оно будет передавать данные услуги BCAST, поставленные от BSA 20, определяет план доставки услуги BCAST, и формирует руководство мобильного вещания.
Управление подпиской (BSM) 40 службы BCAST управляет информацией о подписке и информацией о предоставлении (подготовке) услуг для приема услуги BCAST, и информацией относительно устройства для приема услуги BCAST.
Терминал 50 является терминалом, способным принимать услуги BCAST, и может быть соединен с сетью сотовой связи в соответствии с возможностью терминала. При этом будет полагаться, что терминал 50 является терминалом, который может быть соединен с сетью сотовой связи.
Теперь будет выполнено описание Защиты контента и Защиты услуги в соответствии с примерным вариантом осуществления настоящего изобретения. «Защита контента» защищает пересылаемые файлы и потоки. Управление правами в отношении контентов выполняется посредством терминала. Защищенные контенты зашифровываются посредством BSA 20 и затем пересылаются на терминал 50. Защита услуги защищает пересылаемые файлы и потоки, и шифрование над контентом выполняется посредством BSD/A 30. Защита контента является подобной Защите услуги в терминах защиты контентов. Однако, в отличие от Защиты услуги, Защита контента различается согласно использованию/не использованию DRM. То есть Защита контента включает в себя функцию управления действительным диапазном для контентов, которые терминал получил, и возможностью создания копии контентов. Относительно Защиты контента, контенты зашифровываются посредством BSA 20 и затем пересылаются на Терминал 50.
И для Защиты услуги, и для Защиты контента BSM 40 выполняет управление подпиской на терминале. Если услуга вещания поставлена на терминал 50 через объекты для каждой функции, пользователь терминал 50 может пользоваться услугой. В документе сообщение, относящееся к Защите услуги и Защите контента, будет называться 'информацией шифрования'.
Теперь со ссылкой Фиг.1 будет описан примерный способ доставки сообщения информации шифрования. Чтобы использовать пересылаемые услугу и контенты, Терминал 50 должен зарегистрироваться в BSM 40 и затем принять Материал (RKM) ключа регистрации на этапе 100. После этого, если Терминал 50 выполняет подписку на конкретную услугу вещания, он должен получить на этапе 110 сообщение (LKM) долгосрочного ключа. Кроме этого, Терминал 50 должен получить на этапе 120 Сообщение (SKM) краткосрочного ключа, используемое для фактического расшифровывания зашифрованных контентов и услуги. Терминал 50 может расшифровывать LKM с использованием RKM, и может расшифровывать SKM с использованием Ключа (SEK) шифрования услуги, полученного в результате расшифровывания. SKM включает в себя Ключ (TEK) шифрования трафика, и Терминал 50 может фактически расшифровывать зашифрованную услугу и контенты, используя TEK. На Фиг.1 показано, что сообщения информации шифрования, такие как RKM, LKM и SKM, доставляются от BSD/A 30 на Терминал 50 по каналу вещания. Терминал 50, способный использовать интерактивный канал, хотя не показано на Фиг.1, может в качестве альтернативы принимать RKM и LKM через прямую связь с BSM 40.
Теперь будет выполнено описание элементов примерных сообщений, используемых для доставки информации шифрования.
В таблицах 1 - 6 ниже показаны схематические таблицы описанных выше сообщений, и показаны обычные последовательности определения форматов сообщений, используемых в примерных вариантах осуществления настоящего изобретения, и в таблицах указаны описания каждого поля.
Таблица 1 Формат Req-1 сообщения запроса | |||||
Поле Name | Тип | Категория | Количество элементов | Описание | Тип данных |
Tag | E | М | 1 | Тип сообщения | Integer (целое) |
Version | E | O | 1 | Версия стандарта, поддерживаемого этим сообщением | Integer |
Message ID | E | М | 1 | Идентификатор данного сообщения | String (строковый) |
Destination | E | М | 1 | Идентификатор получателя сообщения | String |
Source | E | М | 1 | Идентификатор источника сообщения | String |
Service/Content Info | E | М | 1 | Связанная информация, такая как идентификатор услуги/контента | String |
Time | E | 0 | 1 | Время, когда доставлено сообщение | String |
Таблица 2 Формат Res-1 сообщения ответа | |||||
Поле Name | Тип | Категория | Количество элементов | Описание | Тип данных |
Tag | E | М | 1 | Тип сообщения | Integer |
Version | E | O | 1 | Версия стандарта, поддерживаемого данным сообщением | Integer |
Message ID | E | М | 1 | Идентификатор сообщения запроса | String |
Destination | E | М | 1 | Идентификатор получателя сообщения | String |
Source | E | М | 1 | Идентификатор источника сообщения | String |
Service/Content Info | E | O | 1 | Связанная информация, такая как идентификатор услуги/контента | String |
Status | E | М | 1 | Результат ответа на сообщение | Integer |
Data | E | O | 1 | Информация, планируемая для доставки получателю | Binary |
Time | E | O | 1 | Время, в которое доставлено сообщение | String |
Таблица 3 Формат Res-2 сообщения ответа | |||||
Поле Name | Тип | Категория | Количество элементов | Описание | Тип данных |
Tag | E | М | 1 | Тип сообщения | Integer |
Message ID | E | М | 1 | Идентификатор сообщения запроса | String |
Status | E | М | 1 | Результат ответа на сообщение | Integer |
Data | E | 0 | 1 | Информация, планируемая для доставки получателю | Binary (двоичный) |
Таблица 4 Формат Tra-1 сообщения доставки | |||||
Поле Name | Тип | Категория | Количество элементов | Описание | Тип данных |
Tag | E | М | 1 | Тип сообщения | Integer |
Version | E | O | 1 | Версия стандарта, поддерживаемого данным сообщением | Integer |
Target Terminal | E | М | 1 | Целевой терминал для этого сообщения | String |
Message ID | E | М | 1 | Идентификатор данного сообщения | String |
Destination | E | М | 1 | Идентификатор получателя сообщения | String |
Source | E | М | 1 | Идентификатор источника сообщения | String |
Service/ContentInfo | E | М | 1 | Связанная информация, такая как идентификатор услуги/контента | String |
Data | E | М | 1 | Информация, планируемая для доставки получателю | Binary |
Time | E | O | 1 | Время, в которое доставлено сообщение | String |
Таблица 5 Формат Con-1 сообщения подтверждения | |||||
Поле Name | Тип | Категория | Количество элементов | Описание | Тип данных |
Tag | E | M | 1 | Тип сообщения | Integer |
Version | E | O | 1 | Версия стандарта, поддерживаемого данным сообщением | Integer |
Message ID | E | M | 1 | Идентификатор сообщения доставки | String |
Destination | E | М | 1 | Идентификатор получателя сообщения | String |
Source | E | М | 1 | Идентификатор источника сообщения | String |
Service/ContentInfo | E | O | 1 | Связанная информация типа идентификатор услуги/контента | String |
Status | E | М | 1 | Результат Подтверждения сообщения | Integer |
Time | E | O | 1 | Время, в которое доставлено сообщение | String |
Таблица 6 Формат Con-2 подтверждения сообщения | |||||
Поле Name | Тип | Категория | Количество элементов | Описание | Тип данных |
Tag | E | М | 1 | Тип сообщения | Integer |
Message ID | E | М | 1 | Идентифиактор сообщения доставки | String |
Status | E | М | 1 | Результат Подтверждения сообщения | Integer |
В таблицах поле Name (поле имени) указывают имена элементов и атрибутов, образующих соответствующее сообщение. «Тип» (type) указывает соответствие соответствующего имени типу элемента или атрибута. Каждый элемент имеет значения E1, E2, E3 и E4. E1 означает верхний элемент для целого сообщения, E2 указывает подэлемент E1, E3 указывает подэлемент E2, и E4 указывает подэлемент E3. Атрибут обозначается посредством A, и А указывает атрибут соответствующего элемента. Например, А под E1 указывает атрибут E1. 'Category' (категория) используется для указания, является ли соответствующий элемент или атрибут обязательным, и имеет значение M, если значение является обязательным, и значение O, если значение является необязательным. 'Cardinality' (количество элементов в связи) указывает связи между элементами, и имеет значения {0, 0..1, 1, 0..n, 1..n}, где "0" означает необязательную связь, "1" означает обязательную связь, и 'n' означает возможность наличия множества значений. Например, '0..n' означает возможность, что соответствующего элемента нет или есть n соответствующих элементов. 'Description' (описание) определяет значение соответствующего элемента или атрибута. 'Data Type' (тип данных) указывает тип данных соответствующего элемента или атрибута.
В нижеследующей Таблице 7 ниже тип каждого сообщения различают, используя поле Tag, используемое в форматах сообщений, определенных в таблицах 1-6. Однако значения Tag, определенные в документе, просто различают типы сообщений, и не являются всегда постоянными, а подлежат изменению согласно условиям.
В сообщении ответа и сообщении подтверждения значение Status='0' указывает, что сообщения запроса и доставки были приняты успешно, и связанный пункт был выполнен, и значение Status='1' указывает, что прием сообщений запроса и доставки был неудачным, и исполнение связанного пункта было неудачным.
Каждое сообщение может получить улучшение характеристики, используя Res-2 или Con-2, которые являются сокращенным сообщением, предусмотренным использующим Message ID, как показано в поле Применяемый формат сообщения из Таблицы 7 ниже.
Таблица 7 Тип Сообщения и Применяемый формат сообщения на основе поля Tag | |||
Поле Tag | Тип сообщения | Применяемый формат сообщения | Информация доставки |
1 | Сообщение запроса TEK | Req-1 | TEK |
2 | Ответное сообщение на запрос TEK | Res-1 или Res-2 | |
3 | Сообщение доставки TEK | Tra-1 | |
4 | Сообщение подтверждения доставки TEK | Con-1 или Con-2 | |
5 | Сообщение запроса SKM | Req-1 | SKM |
6 | Ответное сообщение на запрос SKM | Res-1 или Res-2 | |
7 | Сообщение доставки SKM | Tra-1 | |
8 | Сообщение подтверждения доставки SKM | Con-1 или Con-2 | |
9 | Сообщение запроса LKM | Req-1 | LKM |
10 | Ответное сообщение на запрос LKM | Res-1 или Res-2 | |
11 | Сообщение доставки LKM | Tra-1 | |
12 | Сообщение подтверждения доставки LKM | Con-1 или Con-2 | |
13 | Сообщение запроса RKM | Req-1 | RKM |
14 | Ответное сообщение на запрос RKM | Res-1 или Res-2 | |
15 | Сообщение доставки RKM | Tra-1 | |
16 | Сообщение подтверждения доставки RKM | Con-1 или Con-2 |
Примерные варианты осуществления настоящего изобретения обеспечивают способ для обмена между BSA 20 и BSM 40, и между BSD/A 30 и BSM 40 информацией о шифровании, такой как TEK, SKM, LKM и RKM, относящейся к Защите услуги и Защите контента. На Фиг.2A и 2B показана информация, обмениваемая между объектами, и подробные примеры будут описаны со ссылкой на сопроводительные чертежи.
На Фиг.2A и 2B показаны схемы, иллюстрирующие информационный поток между объектами сервера в соответствии с примерным вариантом осуществления настоящего изобретения для Защиты услуги и Защиты контента, соответственно. Что касается Фиг.2A и 2B, объект для исполнения Защиты услуги включает в себя Защиту-шифрование услуги (SP-E) 31 и Распространение ключа-защиты услуги (SP-KD) 32 в BSD/A 30. SP-E 31 используется, чтобы шифровать услугу, и SP-KD 32 используется, чтобы передавать связанную информацию ключа шифрования на Терминал 50 по каналу вещания. BSM 40, включающее в себе Защиту-управление услуги (SP-M) 41, управляет подпиской терминала и формированием ключа шифрования.
Для Защиты контента (объект) Распространение файла (FD) 33 в BSD/A 30 принимает информацию о ключе шифрования, доставленную от BSM 40, и по каналу вещания доставляет принятую информацию о ключе шифрования на терминал. BSM 40, включающее в себе Защиту-управление контента (CP-M) 42, управляет подпиской терминала и формированием ключа шифрования. BSA 20, включающее в себе Защиту-шифрование контента (CP-E) 21, управляет шифрованием контентов. На Фиг.3А и 3B показаны схемы, иллюстрирующие способ обмена информацией между BSA 20 и BSM 40 для Защиты контента в соответствии с примерным вариантом осуществления настоящего изобретения, и будет описана информация, передаваемая для Защиты контента. В примерном способе Защиты контента, поскольку шифрование выполняется в BSA 20, то сформированный BSM 40 ключ шифрования поставляется на BSA 20. Поскольку ключом, используемым для шифрования контента в мобильной системе вещания, является TEK, то, что сформированный посредством BSM 40 TEK должен быть доставлен на BSA 20.
Как показано на Фиг.3A, примерный способ доставки начинается с сообщения запроса TEK, передаваемого от BSA 20 на этапе 300, и поле Tag, указывающее сообщение запроса TEK, установлено в '1'. Поле Destination указывает BSM 40, и поле Source указывает BSA 20. После приема сообщения запроса TEK, CP-M 42 в BSM 40 на этапе 310 передает ответное сообщение на запрос TEK со значением Tag='2'. Если поле Status в ответе установлено в '0', TEK сохраняется в поле Data перед передачей, и если TEK не передается, поле Status перед передачей устанавливается в '1'.
В способе по Фиг.3B, BSM 40 передает TEK без запроса от BSA 20. В примерном варианте осуществления CP-M 42 в BSM 40 на этапе 320 передает на CP-E 21 в BSA 20 сообщение доставки TEK со значением Tag='3' с наличием TEK, включенного в поле Data. В ответ BSA 20 на этапе 330 передает на BSM 40 сообщение подтверждения доставки TEK со значением Tag='4'. В примерном варианте осуществления поле Status установлено в '0', указывая нормальный прием TEK. Если прием TEK является неудачным, поле Status установлено в '1'.
На Фиг.4 иллюстрируется стек протоколов, образующий интерфейс обмена информацией между BSA 20 и BSM 40 в соответствии с примерным вариантом осуществления настоящего изобретения. Что касается Фиг.4, BSA 20 и BSM 40 могут обмениваться данными путем достижения совместимости друг с другом, используя протокол. Защита доставки данных между BSA 20 и BSM 40 может реализовывать защиту данных без ограничения протокола и данных верхнего уровня, используя протокол IPSec. Протоколы TCP и TTP/TTP присутствуют в качестве верхнего уровня IPSec, и CP-E 21 в BSA 20 и CP-M 42 в BSM 40 присутствуют на нем для обмена сообщениями и связанного действия интерфейса.
На Фиг.5A и 5B иллюстрируется способ получения TEK, в котором BSD/A 30 шифрует и осуществляет вещание услуги для Защиты услуги в соответствии с примерным вариантом осуществления настоящего изобретения.
Что касается Фиг.5A, SP-E 31 в BSD/A 30 на этапе 400 передает на BSM 40 сообщение запроса TEK. Сообщение запроса TEK имеет значение Tag '1', и его поля Destination и Source указывают BSM 40 и BSD/A 30, соответственно. В ответ на сообщение запроса TEK, BSM 40 на этапе 410 передает ответное сообщение на запрос TEK со значением Tag='2'. BSM 40 устанавливает значение поля Status в '0', когда оно передает запрошенный TEK. В противном случае BSM 40 устанавливает значение Status в '1'. Когда значение Status установлено в '0', TEK сохраняется в поле Data сообщения ответа на запрос TEK.
В примерном варианте осуществления, показанном на Фиг.5B, BSM 40 сразу передает TEK без запроса от BSD/A 30. Что касается Фиг.5B, SP-M 41 в BSM 40 на этапе 420 передает на BSD/A 30 сообщение доставки TEK со значением Tag='3' с наличием TEK, включенного в него. В ответ BSD/A 30 на этапе 430 передает на BSM 40 сообщение подтверждения доставки TEK со значением Tag='4'. Если BSD/A 30 успешно принял TEK, он устанавливает в '0' значение Status в сообщении подтверждения доставки TEK. Однако, если BSD/A 30 потерпел неудачу в приеме TEK, он устанавливает значение Status в '1'.
На Фиг.6 показана схема, иллюстрирующая стек протоколов для интерфейса обмена информацией между BSD/A 30 и BSM 40 для Защиты услуги в соответствии с примерным вариантом осуществления настоящего изобретения. Безопасность между интерфейсами защищается с использованием протокола IPSec, и протокол, относящийся к способу защиты услуги передается через TCP и HTTP/HTTPS. Переданной от BSM 40 информацией о шифровании управляет BSD/A 30, и информация шифрования включает в себя RKM, LKM, SKM и TEK.
На Фиг.7A и 7B показаны схемы, иллюстрирующие способ получения SKM посредством BSD/A 30 в соответствии с примерным вариантом осуществления настоящего изобретения. Этот примерный способ можно применяться для Защиты услуги и/или контента. SKM является ключом шифрования, с помощью которого терминал может расшифровывать услугу или контент, зашифрованные посредством BSD/A 30. SKM может быть доставлен от BSM 40 на Терминал 50 по интерактивному каналу. Однако в среде канала вещания, SKM должен доставляться от BSD/A 30 на Терминал 50 по каналу вещания.
Что касается Фиг.7A, BSD/A 30 на этапе 500 передает на BSM 40 сообщение запроса SKM. В BSM 40, объектом для обработки сообщения может быть SP-M 41 для Защиты услуги и/или CP-M 42 для Защиты контента. Сообщение запроса SKM имеет значение '5' поля Tag, и его поля Destination и Source указывают BSM 40 и BSD/A 30, соответственно. В ответ на сообщение запроса SKM, BSM 40 на этапе 510 передает сообщение ответа на запрос SKM со значением Tag='6'. Когда BSM 40 передает запрошенное SKM, оно устанавливает значение Status в '0' и поле Data в SKM. В противном случае, когда BSM 40 не может передавать SKM, оно устанавливает значение Status в '1'.
В примерном показанном на Фиг.7B варианте осуществления BSM 40 сразу передает SKM без запроса от BSD/A 30. BSM 40 на этапе 520 передает на BSD/A 30 сообщение доставки SKM со значением Tag='7' с наличием SKM, включенного в него. В ответ BSD/A 30 на этапе 530 передает на BSM 40 сообщение подтверждения доставки SKM со значением Tag='8'. Если BSD/A 30 успешно принял SKM, он устанавливает значение Status в сообщении подтверждения поставки SKM в '0'. Однако, если BSD/A 30 потерпел неудачу в приеме SKM, он устанавливает значение Status в '1'.
Для Защиты услуги этот процесс управляется посредством SP-KD 32 в BSD/A 30 и SP-M 41 в BSM 40. Для Защиты контента этот процесс управляется посредством FD 33 в BSD/A 30 и CP-M 42 в BSM 40.
На Фиг.8A и 8B показаны схемы, иллюстрирующие способ получения LKM посредством BSD/A 30 в соответствии с примерным вариантом осуществления настоящего изобретения. В способе Защиты услуги/контента информацией LKM обмениваются с использованием канала вещания. LKM может доставляться от BSM 40 на Терминал 50 по интерактивному каналу. Однако в среде канала вещания LKM должно быть доставлено от BSD/A 30 на Терминал 50 по каналу вещания.
Что касается Фиг.8A, на этапе 600 BSD/A 30 передает на BSM 40 сообщение запроса LKM. Сообщение запроса LKM имеет значение '9' поля Tag, и его поля Destination и Source указывают BSM 40 и BSD/A 30, соответственно. В ответ на сообщение запроса LKM, BSM 40 на этапе 610 передает сообщение ответа на запрос LKM со значением Tag='10'. Когда BSM 40 намеревается передавать запрошенный LKM, оно устанавливает значение Status в '0'. В противном случае BSM 40 устанавливает значение Status в '1'. Когда значение Status установлено в '0', LKM сохраняется в поле Data. Когда значение Status установлено в '1', сообщение ответа на запрос LKM передается без поля Data.
В случае Фиг.8B, BSM 40 напрямую передает LKM без ответа от BSD/A 30. В этом случае BSM 40 на этапе 620 передает на BSD/A 30 сообщение доставки LKM со значением Tag='11' с наличием включенного в него LKM. В ответ BSD/A 30 на этапе 630 передает на BSM 40 сообщение подтверждения доставки LKM со значением Tag='12'. Если BSD/A 30 успешно принял LKM, он устанавливает в '0' значение Status сообщения подтверждения поставки LKM. Однако, если BSD/A 30 потерпел неудачу в приеме LKM, он устанавливает значение Status в '1'.
Для Защиты услуги этот процесс управляется посредством SP-KD 32 в BSD/A 30 и SP-M 41 в BSM 40. Для Защиты контента этот процесс управляется посредством FD 33 в BSD/A 30 и CP-M 42 в BSM 40.
На Фиг.9A и 9B показаны схемы, иллюстрирующие способ получения RKM посредством BSD/A 30 для Защиты услуги и Защиты контента в соответствии с примерным вариантом осуществления настоящего изобретения.
RKM может доставляться от BSM 40 на Терминал 50 по интерактивному каналу. Однако в среде канала вещания RKM должен быть доставлен от BSM 40 на Терминал 50 по каналу вещания.
Что касается Фиг.9A, BSD/A 30 на этапе 700 передает на BSM 40 сообщение запроса RKM. Сообщение запроса RKM имеет значение '13' поля Tag, и его поля Destination и Source указывают BSM 40 и BSD/A 30, соответственно. В ответ на сообщение запроса RKM, BSM 40 на этапе 710 передает на BSD/A 30 сообщение ответа на запрос RKM со значением Tag='14'. Когда BSM 40 намеревается передавать запрошенный RKM, он устанавливает значение Status в '0'. В противном случае BSM 40 устанавливает значение Status в '1'. Если значение Status установлено в '0', RKM сохраняется в поле Data перед передачей. Однако, если значение Status установлено в '1', сообщение ответа на запрос RKM передается без поля Data.
В случае Фиг.9B, BSM 40 сразу передает RKM без запроса от BSD/A 30. В примерном варианте осуществления BSM 40 на этапе 720 передает на BSD/A 30 сообщение доставки RKM со значением Tag='15' с наличием включенного в него RKM. В ответ BSD/A 30 передает RKM сообщение подтверждения доставки с Tag='16' на BSM 40 на этапе 730. Если BSD/A 30 успешно принял RKM, он устанавливает в '0' значение Status сообщения подтверждения доставки RKM. Однако, если BSD/A 30 потерпел неудачу в приеме RKM, он устанавливает значение Status в '1'.
Для Защиты услуги этим процессом управляет SP-KD 32 в BSD/A 30 и SP-M 41 в BSM 40. Для Защиты контента этим процессом управляет FD 33 в BSD/A 30 и CP-M 42 в BSM 40.
На Фиг.10 иллюстрируется стек протоколов для интерфейса обмена информацией между BSD/A 30 и BSM 40 для Защиты услуги в соответствии с примерным вариантом осуществления настоящего изобретения. Безопасность между интерфейсами защищается с использованием протокола IPSec, и протокол, относящийся к способу защиты услуги, передается через TCP и HTTP/HTTPS. Связанная информация шифрования включает в себя TEK, SKM, LKM и RKM.
На Фиг.11 иллюстрируется стек протоколов для интерфейса между BSD/A 30 и BSM 40, предназначенного для Защиты контента, в соответствии с примерным вариантом осуществления настоящего изобретения. Безопасность между интерфейсами защищается с использованием протокола IPSec, и протокол, связанный со способом защиты контента, передается через TCP и HTTP/HTTPS. Связанная информация шифрования включает в себя SKM, LKM и RKM.
Теперь со ссылкой на Фиг.12 будет выполнено описание Терминала 50 в соответствии с примерным вариантом осуществления настоящего изобретения.
Как проиллюстрировано на Фиг.12, Терминал 50 в соответствии с примерным вариантом осуществления настоящего изобретения содержит модуль 1200 приложения, модуль 1210 DRM, модуль 1235 аутентификации, модуль 1260 защищенного хранилища, модуль 1265 обмена информацией, и модуль 1270 (UIM I/F) интерфейса модуля идентификации пользователя (абонента).
Конкретно, модуль 1200 приложения, которым может быть модуль подобный Media Player , используется для воспроизведения расшифрованного контента, поставленного от модуля 1210 DRM, и модуль 1210 DRM используется для управления регистрацией, подписки на услуги и использования контента.
Модуль 1210 DRM может включать в себя модуль 1213 управления DRM, модуль 1215 регистрации, модуль 1220 управления правами, модуль 1225 управления потоком ключей, и модуль 1230 расшифровывания контента. Относительно модулей, модуль 1215 регистрации выполняет действие регистрации, и модуль 1220 управления правами управляет анализом и использованием информации о правах, полученной в течение подписки на услуги. Модуль 1225 управления потоком ключей выполняет действие расшифровывания зашифрованного ключа трафика с помощью ключа услуги, и модуль 1230 расшифровывания контента выполняет действие расшифровывания зашифрованных контентов с помощью ключа трафика. Полное действие связанных с DRM модулей выполняется под управлением модуля 1213 управления DRM.
Модуль 1235 аутентификации управляет исполнением протокола аутентификации вместе с модулем идентификации пользователя и сетью, например, поставщиком услуг, и выполняет формирование сообщения и верификацию, используя свой модуль более низкого уровня. Модуль 1235 аутентификации может включать в себя администратор 1240 аутентификации, чтобы осуществлять контроль исполнения полного протокола и управление функцией аутентификации, модуль 1245 расшифровывания-шифрования для выполнения действия расшифровывания/шифрования с помощью своего модуля более низкого уровня, модуль 1250 цифровой подписи для управления электронной подписи, и модуль 1255 MAC, для выполнения операции MAC.
Конкретно, модуль 1210 DRM и модуль 1235 аутентификации получают ключ группы путем верификации сообщения ответа регистрации, принятого от BSM 40 в соответствии с примерным вариантом осуществления настоящего изобретения, и получают информацию о правах из сообщения ответа подписки на услуги, принятого от BSM 40 с использованием ключа группы. Кроме того, после приема сообщения ключа трафика от BSD/A 30, модуль 1210 DRM и модуль 1235 аутентификации получают ключ трафика с использованием информации о правах, и расшифровывают переданную от BSD/A 30 зашифрованную услугу с использованием полученного ключа трафика.
Модуль 1265 обмена информацией, отвечающий за связь с сетью, принимает сообщение от сети и передает соответственное ответное сообщение в ответ на принятое сообщение. Конкретно, согласно варианту осуществления настоящего изобретения модуль 1265 обмена информацией принимает сообщение от BSD/A 30 по каналу вещания. Согласно другому примерному варианту осуществления настоящего изобретения модуль 1265 обмена информацией обменивается сообщениями с BSM 40 по интерактивному каналу, и принимает от BSD/A 30 сообщение ключа трафика и зашифрованную услугу.
Модуль 1260 защищенного хранилища хранит ключи шифрования, и модуль 1270 UIM I/F несет ответственность за связь с модулем идентификации пользователя (UIM) (не показано).
Как может быть понято из предшествующего описания, настоящее изобретение обеспечивает интерфейсы для передачи информации шифрования между объектами, таким образом обеспечивая надежную защиту услуги/контента для службы вещания.
Несмотря на то, что изобретение было показано и описано со ссылкой на примерные варианты его осуществления, специалистам в данной области техники будет понятно, что в нем могут быть выполнены различные изменения в форме и деталях без выхода за рамки объема и существа изобретения, как определено согласно прилагаемой формуле изобретения.
Класс H04W12/04 распределение ключей
Класс H04L9/28 с использованием специального алгоритма шифрования