ЦИФРОВЫЕ ПОДПИСИ ДЛЯ ПРИЛОЖЕНИЙ ЦИФРОВОГО ТЕЛЕВИДЕНИЯ Российский патент 2008 года по МПК H04N7/16 G06F21/00 

РОДСТВЕННЫЕ ЗАЯВКИ НА ПАТЕНТ

Данная заявка на патент требует приоритет предварительной заявки США № 60/417404, поданной 8 октября 2002 года и включенной во всей своей полноте в настоящее описание в качестве ссылки.

ОБЛАСТЬ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Данное изобретение относится в целом, но не исключительно, к защите дополнительного или интерактивного телевизионного контента (содержимого), а более конкретно, но не исключительно, относится к подписанию дополнительного или интерактивного телевизионного контента.

УРОВЕНЬ ТЕХНИКИ

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

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

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

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

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

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

Подробное описание изложено со ссылками на сопутствующие чертежи.

Фиг.1 является примерной блок-схемой файла ресурса информации безопасности.

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

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

На Фиг.4 изображена примерная XML схема метаданных для файла ресурса информации безопасности в централизованной архитектуре.

На Фиг.5 изображена примерная XML схема метаданных для элемента определения местоположения файла отдельной подписи для файла ресурса информации безопасности в централизованной архитектуре, изображенного на Фиг.4.

На Фиг.6 изображена примерная XML схема метаданных для элемента для указания делегированной (уполномоченной) информации для файла ресурса информации безопасности в централизованной архитектуре, изображенного на Фиг.4.

На Фиг.7 изображена примерная XML схема метаданных для элемента для указания делегированных ограничений для файла ресурса информации безопасности в централизованной архитектуре, изображенного на Фиг.4.

На Фиг.8 изображена примерная XML схема метаданных для элемента для указания информации о кластере для файла ресурса информации безопасности в централизованной архитектуре, изображенного на Фиг.4.

На Фиг.9 изображена примерная XML схема метаданных для элемента для указания информации о кластере для файла ресурса информации безопасности в централизованной архитектуре, изображенного на Фиг.4.

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

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

На Фиг.12 изображена примерная XML схема метаданных для файла ресурса информации безопасности в децентрализованной архитектуре.

На Фиг.13 изображена примерная XML схема метаданных для метки времени версии.

На Фиг.14А-14В изображен примерный способ ассоциирования приложения дополнительного контента с его цифровой подписью.

На Фиг.15 изображен примерный способ обработки цифровой подписи при получении приложения дополнительного телевизионного контента.

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

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

Перед описанием вариантов осуществления изобретения полезно описать некоторые концепции, применяемые в настоящем описании. Дополнительный контент составлен из отдельных файлов. Набор таких отдельных файлов называется приложением. Обычно, в телевидении, имеющем дополнительный контент (содержимое), приложение начинается со стартового файла. Стартовый файл представляет собой файл или структуру данных, которые описывают параметры, требуемые для выполнения приложения. Поднабор файлов приложения называется кластером. Кластеры являются полезными при группировке файлов, которые могут иметь логическую организацию и могут иметь общую подпись. Например, все файлы, представляющие объекты для веб-страницы, могут составлять логический кластер. Аналогично, все веб-страницы, образующие раздел в электронной газете, могут составлять другой логический кластер. Главный кластер является поднабором файлов приложения, который включает в себя файл ресурса информации безопасности, как это описано ниже.

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

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

Говорится, что кластер является статическим в течение временного интервала, если каждый файл в кластере является статическим, и набор файлов в кластере остается постоянным. Говорится, что кластер является динамическим в течение интервала времени, если в течение интервала времени он не является статическим.

Веб-Страница или Кластер Веб-Страницы является группой файлов (например, текстовые файлы, графические файлы, файлы скриптов (сценариев)), которые могут быть отображены вместе в виде одной страницы. Файл Веб-Страницы является файлом, включающим в себя язык гипертекстовой разметки (HTML) или расширяемый язык гипертекстовой разметки (XHTML) (или другое представление разметки) и который описывает представление и структуру для Кластера Веб-Страницы.

Отдельная подпись представляет собой подпись, которая существует в виде отдельного файла и которая применяется для подписи одного или более файлов приложения, например, каждого из файлов, составляющих кластер. Присоединенная подпись представляет собой подпись, которая существует в виде внутренних данных в файле, и которая применяется для подписи файла, который содержит данную подпись. Если файл, содержащий подпись, является Файлом Веб-Страницы, который является составной частью Кластера Веб-Страницы, та же подпись может быть использована для подписи файлов в Кластере Веб-Страницы.

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

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

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

Файл Ресурсов Информации Безопасности

На Фиг.1 изображен примерный файл 100 ресурсов информации безопасности. Файл 100 ресурсов информации безопасности представляет собой набор выражений, который предоставляет исчерпывающую информацию о подписи приложения. Файл 100 ресурсов информации безопасности в централизованной архитектуре может существовать в виде дополнительных данных в стартовом файле или в виде отдельного файла, на который в стартовом файле имеется указатель. Файл 100 ресурсов информации безопасности в децентрализованной архитектуре может существовать в виде присоединенного файла в файле приложения или Веб-Страницы.В одной реализации файл 100 ресурсов информации безопасности реализован с применением языка разметки, такого как Расширяемый Язык Разметки (XML). XML представляет собой гибкий способ создания общих информационных форматов и распределения как формата, так и данных во "Всемирной Паутине", сетях интранет и др. В одной реализации файл 100 ресурсов информации безопасности является подписанным для предотвращения неавторизованной модификации информации.

В централизованной архитектуре файл 100 ресурсов информации безопасности включает в себя информацию о кластере в виде выражения 110 метаданных для каждого определенного кластера приложения для идентификации каждого кластера. Кластеры применяются для группировки файлов таким образом, что для подписи кластера используется одна цифровая подпись, вместо отдельного подписания каждого файла в кластере. В централизованной архитектуре файл 100 ресурсов информации безопасности включает в себя выражение 120 метаданных местоположения подписи для каждого идентифицированного кластера. Выражение 120 метаданных местоположения подписи для каждого идентифицированного кластера описывает местоположение отдельной подписи для кластера, например как Универсальный Указатель Ресурсов (URL) или ссылка.

Файл 100 ресурсов информации безопасности может включать в себя выражения 130 метаданных, которые описывают другую информацию о приложениях с цифровой подписью. Выражения 130 метаданных, описывающие другую информацию, в одной реализации могут включать в себя выражения 140 метаданных, описывающие стратегию защиты, и имеющие ссылки на документы, описывающие стратегии защиты. Выражения 130 метаданных, описывающие другую информацию, в одной реализации могут представлять выражения 150 метаданных, описывающие делегирование, и идентифицирующие уполномоченных, которые могут подписать кластер, по меньшей мере, для одного идентифицированного кластера (кластеров) дополнительно к главному подписывающему лицу или уполномоченных, которые могут подписать приложение дополнительно к главному подписывающему лицу. Некоторые компоненты приложения могут генерироваться сторонами, отличными от основной сущности. В одной реализации приемники дополнительных приложений распознают такие другие стороны как доверенные исходные сущности. Например, сеть, по которой идет распространение программного обеспечения сотням широковещательных филиалов, может позволить филиалам вставлять компоненты программного обеспечения для местных коммерсантов. Под термином "уполномоченный" понимается некоторая сторона, отличная от сущности, являющейся главным источником, и которая подписывает части приложения, применяя отдельные подписи кластера, присоединенные подписи файлов или присоединенные подписи сообщений.

Ниже приведены примеры как централизованной, так и децентрализованной архитектур файла 100 ресурсов информации безопасности и централизованной, и децентрализованной систем.

Централизованные архитектуры.

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

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

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

Файл 100 ресурсов информации безопасности централизованной архитектуры включает в себя выражение 110_i метаданных информации о кластерах для каждого кластера "i", i=1...n, именующее каждый кластер "i". Файл 100 ресурсов информации безопасности централизованной архитектуры включает в себя выражение 120_i метаданных местоположения подписи для каждого идентифицированного кластера 214_i, i=1...n. Выражение 120_i метаданных местоположения подписи описывает местоположение файла 210_i отдельной подписи для кластера 214_i, например такое, как URL или ссылка. Каждый кластер 214_i ассоциирован с соответствующими файлами 220. В качестве иллюстрации, кластер 214_i ассоциирован с файлами 220₁-220_m, а кластер 214n ассоциирован с файлами 220t-220v. Файл 210i отдельной подписи включает в себя цифровую подпись 211i кластера 214i_. Подпись 211i может включать в себя хэш-коды каждого из файлов, составляющих кластер, и цифровую подпись для подписи, по меньшей мере, хеш-кодов каждого из файлов. Процесс подписания кластера включает вычисление цифровой подписи 211i кластера. Для статического кластера цифровая подпись может быть вычислена только один раз. Для динамического кластера подпись кластера может вычисляться каждый раз при изменении файла в кластере. Таким образом, выбор кластера должен отражать количество файлов в кластере, так же как и динамическую природу файлов в кластере. Файл 210_i цифровой подписи может включать в себя указатель на файлы 212_i кластера, указывающий местоположение или идентификацию файлов 220, составляющих кластер 214_i. В одной реализации указатель на файлы хранится вне файла 210_i подписи, например, в файле 100 ресурсов информации безопасности. Файл 210_i цифровой подписи может включать в себя запись 213_i проверки времени для описания версии подписи как функции файлов 220_i, составляющих кластер 214_i. Это может применяться для определения, соответствует ли подпись 211_i текущим файлам кластера в случае динамического кластера. В одной реализации запись 213_i проверки времени хранится вне файла 210_i подписи, например, в файле 100 ресурсов информации безопасности.

На Фиг.3 изображена реализация централизованной архитектуры, в которой указатель для получения доступа к указателю на данные цифровой подписи включены в стартовый файл. Как изображено на Фиг.3, стартовый файл 302 включает в себя указатель на файл 100 ресурсов информации безопасности централизованной архитектуры. Как излагалось со ссылкой на Фиг.2, файл 100 ресурсов информации безопасности централизованной архитектуры включает в себя выражение 110 метаданных информации кластеров для кластеров от 1 до "n" и выражение 120 метаданных местоположения подписи для кластеров от 1 до "n", которое определяет местоположение файлов 210₁-210_n подписей кластеров, причем каждый файл 210_i содержит отдельную цифровую подпись 211_i, ассоциированную соответственно с кластером 214_i. В одной реализации файл 100 ресурсов информации безопасности централизованной архитектуры также включает в себя выражения 130 метаданных другой информации, такой как ссылки на документы, описывающие стратегии защиты; и идентификаторы, свойства и ограничения уполномоченных (если они есть), которые могут подписывать приложение.

На фиг.4 представлена примерная XML схема 400 метаданных для определения структуры и компонентов 408 примерного корневого документа файла 100 ресурсов информации безопасности централизованной архитектуры. Элемент AppSecurityInfo 404 является корневым документом. Компоненты 408 включают в себя элемент MainCluster 412, элемент Delegate 416, и элемент ClusterList 420.

На фиг.5 представлена иллюстративная схема 500 метаданных для задания структуры элемента MainCluster 412 (Фиг.4) Элемент MainCluster 504 задает местоположение файла 210_i отдельной подписи (Фиг.2 или 3). Атрибут Loc 508 указывает местоположение, откуда файл подписи (основного кластера) может быть получен, в формате Универсального Идентификатора Ресурсов (URI). Атрибут Id 512 необязателен и применяется для ссылок на элемент MainCluster из других частей родительского документа или других документов.

На фиг.6 представлена иллюстративная схема 600 метаданных для определения (задания) структуры элемента Delegate 416 (Фиг.4). Элемент Delegate 416 задает идентификацию имени для записей об уполномоченных, способных подписывать часть приложения с разрешения Главной Сущности-Источника для приложения. Этот элемент может располагаться вне или внутри списка кластеров в метаданных 100 информации о подписи для централизованной архитектуры.

Расположение вне списка кластера может указывать, что именованный уполномоченный может подписывать различные части приложения без ограничений. Уполномоченный может подписывать файлы, применяя файлы подписи кластеров, присоединенные файлы подписей, или присоединенные сообщения-подписи. В частности, уполномоченный может подписать "триггерные" (присоединенные) ресурсы (один из видов присоединенного файла подписи). Расположение внутри списка кластера может указывать, что именованный Уполномоченный может подписывать только файл подписи соответствующего кластера.

Элемент DName 604 предоставляет отличительное имя уполномоченного для сравнения с аналогичной информацией в сертификате уполномоченного. Нулевое или большее количество элементов, называемых Constraint 608, могут описывать ограничения в возможности подписи частей приложения. Следующая схема определяет элемент DName: <element name="DName" type="string"/>. Правила для точного представления отличительного имени в виде текстовой строки аналогичны правилам кодирования элемента X509SubjectName, описанных в XML Digital Signature Standard, RFC 3275, "XML-Signature Syntax and Processing", Internet Engineering Task Force (IETF), March 2002.

На фиг.7 представлена иллюстративная схема 700 метаданных для задания структуры элемента Constraint 704. Элемент Constraint 704 определяет (задает) ограничения, которые могут быть наложены на уполномоченных. Элемент 708 notBefore и элемент 712 notAfter являются одной реализацией для обеспечения ограничения по времени возможности уполномоченного подписывать части приложения.

На фиг.8 представлена иллюстративная схема 800 метаданных для задания структуры элемента ClusterList 420 (Фиг.4). Элемент ClusterList 420 определяет оболочку для всех кластеров, составляющих приложение.

На фиг.9 представлена иллюстративная схема 900 метаданных для задания структуры элемента Cluster 904. Атрибут Loc 908 указывает URI, из которого будет взят файл подписи кластера. Атрибут ID 912 необязателен и применяется для организации ссылок на элемент Cluster 904 из других частей родительского документа или других документов.

Децентрализованные архитектуры.

Файл 100 ресурсов информации безопасности описан с использованием XML схемы. Децентрализованная архитектура описывает файл 100 ресурсов информации безопасности как присоединенный файл. Данные подписи в децентрализованной архитектуре являются, альтернативно, присоединенными данными подписи или отдельным файлом отдельной подписи, когда присоединенная ссылка в Веб-Странице указывает на файл отдельной подписи.

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

На Фиг.10 изображена реализация децентрализованной архитектуры, в которой файл 1008₁ ресурса информации безопасности и данные 1009₁ подписи организованы в виде присоединенных файлов. На Фиг.10 файлы 1002₁-1002_n составляют Веб-Страницу 1004. Файл 1002₁ может включать в себя файл 1008 ресурсов информации безопасности. Файл 1008 ресурсов информации безопасности включает в себя необязательную информацию о подписании Веб-Страницы 1004, такую как ссылки на документы, описывающие стратегии защиты; и идентификаторы, свойства и ограничения уполномоченных (если они есть), которые могут подписывать приложение. Файл 1002₁ включает в себя присоединенные данные 1009₁ подписи для Веб-Страницы 1004. В одной реализации данные 1009₁ подписи могут быть включены как компонент файла 1008₁ ресурсов информации безопасности.

На Фиг.11 изображена реализация децентрализованного подхода, в котором файл 100 ресурсов информации безопасности организован как присоединенный файл. На Фиг.11, файлы 1102₁-1102_n составляют Веб-Страницу 1104. Файл 1102₁ может включать в себя файл 100 ресурсов информации безопасности. Файл 100 ресурсов информации безопасности включает в себя необязательную информацию о подписи Веб-Страницы 1104 такую, как ссылки на документы, описывающие стратегии защиты, и идентификаторы, свойства и ограничения уполномоченных (если они есть), которые могут подписывать приложение. Файл 1102₁ включает в себя данные 1109₁ указателя подписи указывающие (или ссылающиеся) на файл 1112 отдельной подписи.

На фиг.12 представлено иллюстративное представление файла ресурсов информации безопасности децентрализованной архитектуры в виде метаданных XML. Представление 1200 в виде метаданных XML начинается и оканчивается элементами 1204 <AppSecurityInfo>, также как и в иллюстративном централизованном подходе со ссылками на схему 400 централизованной архитектуры, изображенной на Фиг.4. Необходимо отметить, что в отличие от схемы 400 централизованной архитектуры, децентрализованное представление не несет информации о кластерах, так как децентрализованная архитектура не требует заблаговременно информации о кластерах. В одной реализации внутри элементов 1204 <AppSecurityInfo> может присутствовать информация для стратегий и уполномоченных.

Представлены в иллюстративных целях две декларации стратегий. Первая декларация 1206 стратегии определяет местоположение PRF (Файл Запроса Разрешения) 1210. Обычно PRF указывает разрешенные и неразрешенные операции для приложения. Необходимо заметить, что атрибут, называемый "Status" 1212, указывает, должна ли быть схема 1200 интерпретирована и декодирована для целей безопасности. Вторая декларация 1216 стратегии определяет местоположение файла, который может содержать соглашение о неразглашении от разработчика приложения. Аналогично могут быть включены другие файлы стратегий.

Схема 1200 включает в себя список Уполномоченных (Delegates) 1220. Уполномоченные являются сущностями (лицами или организациями), которые могут подписывать части приложения в дополнение к главному подписывающему лицу. Необходимо заметить, что <Constraint> 1224 имеет формат, отличный от представленного на Фиг.7. Это является вопросом предпочтения форматов и не имеет технического значения.

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

<link rev="ClusterSignature" type+"text/xml"href="..."/>

Атрибут "href" предоставляет абсолютное или относительное местоположение файла подписи кластера. Когда веб-устройство встречается с XHTML (или HTML) страницей, содержащей в заголовке элемент "link" такого типа, оно восстанавливает ассоциированный файл подписи для проверки подписи. Если проверка подписи успешна, веб-устройство исполняет и отображает XHTML или HTML страницу.

Формат Файла Подписи

В одной реализации формат файла подписи содержит поднабор элементов XML Digital Signature Standard, RFC 3275, "XML-Signature Syntax and Processing", Internet Engineering Task Force (IETF), March 2002. Иллюстративный поднабор, содержащий выражения метаданных и комментарии, приведен ниже в таблице.

ТаблицаЭлементы [XML-DSIG]Поддерживаемые условияSignatureОбязателен. Определяет корневой элемент.SignedInfoОбязателен. Определяет множество ссылок для дайджеста и подписей.SignatureValueОбязателен. Содержит действительную подпись документа.KeyInfoОбязателен. Определяет механизмы извлечения сертификата.ObjectОбязателен. Содержит специальную метку времени для определения версии.CanonicalizationMethodОбязателен, но алгоритмы могут быть ограничены до одного алгоритма канонизации (С14n без комментариев).SignatureMethodОбязателен, но алгоритмы могут быть ограничены до RSA с SHA1.ReferenceОбязателен. Обеспечивает функцию ссылок на внешние файлы и внутренние объекты в конструкции "Signature".TransformsОбязателен, но возможно разрешает только ограниченное количество преобразований: канонизацию и удаление присоединенных подписей.DigestMethodОбязателен. Определяет стандартный SHA-1 алгоритм в качестве средства предоставления хэш-функции сообщения.DigestValueОбязателен. Содержит действительное значение дайджеста для данной Reference.KeyNameМожет быть необязательным при начальной реализации.KeyValueМожет быть необязательным при начальной реализации.RetrievalMethodОбязателен. Применяется для получения исходных сертификатов X.509 из некоторого местоположения.X509DataОбязателен. Некоторые из его дочерних элементов используются для поддержки сертификатов X.509 и CRL.PGPDataНе обязательно. PGP находится вне рамок этих видов цифровой подписи.SPKIDataНе обязательно. SPKI находится вне рамок этих видов цифровой подписи.MgmtDataНе обязательно. Не поддерживается [XML-DSIG].DSAKeyValueНеобязательно при начальной реализации.RSAKeyValueНеобязательно при начальной реализации.P, Q, G, J, Y, Seed, PgenCounterНе обязательно. DSA и его криптографические атрибуты находится вне исходных рамок этих видов цифровой подписи.Modulus, ExponentНеобязательно при начальной реализации. Отдельные объявления криптографических атрибутов RSA не требуются при использовании сертификатов.X509IssuerSerialНеобязательно при начальной реализации. Информация X509 будет передаваться с использованием сертификатов.X509SKIНеобязательно при начальной реализации. Информация X509 будет передаваться с использованием сертификатов.X509SubjectNameНеобязательно при начальной реализации. Информация X509 будет передаваться с использованием сертификатов.X509CertificateОбязателен. Используется для вставки сертификата при необходимости.X509CRLОбязателен. Используется для вставки CRL при необходимости.PGPKeyIDНе обязательно. PGP находится вне рамок этих видов цифровой подписи.PGPKeyPacketНе обязательно. PGP находится вне рамок этих видов цифровой подписи.SPKISexpНе обязательно. SPKI находится вне рамок этих видов цифровой подписи.ManifestОбязателен. Определяет наименее жесткую связь между дайджестом и файлами в течение основной процедуры проверки.SignaturePropertiesОбязателен. Будет содержать временную метку подписи для определения версии.

Поднабор включает в себя набор элементов <Reference>, каждый из которых определяет местоположение файла, и который также определяет преобразования и алгоритмы для подписей. Элемент <KeyInfo> определяет местоположение дополнительных компонентов инфраструктуры открытого ключа (PKI) для обеспечения подписи. Дополнительные компоненты PKI включают в себя сертификаты и списки аннулированных сертификатов. <DigestValue> предоставляет результат односторонней математической хэш-функции для файла. После получения файла приемник выполняет аналогичные операции над принятым файлом. Идентичные значения дайджестов являются необходимым условием верификации подписи. Элемент <SignatureValue> содержит действительные байты подписи производные от подходящих преобразований и алгоритмов подписи. Процедуры преобразования включают в себя канонизацию, способ минимизации и исключения несущественной информации из файла перед применением цифровых подписей.

Элемент <VersionNumber> предназначен для идентификации самой последней версии цифровой подписи. Этот элемент не определен в XML Digital Signature Standard, но является новой реализацией для обеспечения возможности отслеживать старые файлы приемными устройствами. Когда приемные устройства кешируют множество версий подписи, имеется необходимость определить, какая из этих версий наиболее свежая.

Контроль Версий при помощи Метки Времени

В одной реализации метка времени используется для обеспечения версий для файлов подписи, но также служит для обеспечения источника неотвергаемых операций. В реализациях, имеющих динамические кластеры, контроль версий при помощи метки времени должен обеспечивать версии для файлов подписи, которые также служат для обеспечения неотвергаемых операций. Эта конструкция может быть включена в файлы подписи кластеров, а также присоединенные к подписи файлов. По Фиг.13, схема 1300 может быть включена в файлы подписей в отдельным пространстве имен, используя элемент <SignatureProperties> из XML Digital Signature Standard, RFC 3275, "XML-Signature Syntax and Processing", Internet Engineering Task Force (IETF), March 2002.

Вариант осуществления изобретения для создания и верификации дополнительного контента.

На Фиг.14А-14В изображен способ 1400 ассоциации приложений и их цифровых подписей. В одной реализации, по меньшей мере, один процессор, по меньшей мере, в одном сервере дополнительного телевизионного контента включает в себя инструкции, которые при выполнении процессором(процессорами) приводят к выполнению процессором(процессорами) способа 1400.

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

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

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

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

Операция 1416 образует выражение, которое включает в себя местоположение файла подписи, для файлов, подлежащих кластеризации. В одной реализации это представляет собой файл 100 ресурсов информации безопасности, описанный со ссылками на Фиг.1, и Фиг.4-9 и Фиг.13. В одной реализации файл 100 ресурсов информации безопасности является выражением XML метаданных. Как изложено со ссылками на Фиг.1, файл ресурсов информации безопасности может включать в себя выражение, описывающее информацию о кластерах, выражение, описывающее местоположение подписи, и выражения, описывающие другую информацию. В одной реализации файл метаданных ресурсов безопасности подписывают, для того чтобы предотвратить неавторизованную модификацию информации. Операция 1420 сохраняет выражение, или ссылку на выражение, в стартовом файле.

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

Операция 1428 определяет подпись для каждой веб-страницы. Для каждой веб-страницы операция 1432 кодирует в веб-страницу либо подпись, либо указатель на отдельную подпись. Операция 1436 необязательно кодирует в каждой веб-странице выражение, содержащее информацию о защите (безопасности). В одной реализации это представляет собой файл 100 ресурсов информации безопасности, описанный со ссылками на Фиг.1 и Фиг.12. В одной реализации файл 100 ресурсов информации безопасности является выражением XML метаданных. Как изложено со ссылками на Фиг.1, файл ресурсов информации безопасности для децентрализованной архитектуры включает в себя другую информацию о приложениях с цифровой подписью, такую как указатели на документы, описывающие стратегии безопасности и идентификаторы уполномоченных, которые могут подписывать приложение в дополнение к главному подписывающему лицу. В одной реализации файл ресурсов информации безопасности подписывают для того, чтобы предотвратить неавторизованную модификацию информации.

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

Операция 1504 определяет, организованы ли какие-либо файлы в кластер для варианта осуществления с централизованной архитектурой. В одной реализации принимается и декодируется стартовый файл приложения. Если стартовый файл приложения включает в себя или ссылается (указывает на) файл ресурсов информации безопасности, файл ресурсов подписи указывает на присутствие файлов, организованных в кластер. Стартовый файл представляет собой файл инициации или структуру данных, содержащую параметры выполнения приложения, и который обычно указывает на загрузочный файл приложения, который запускает реальное выполнение приложения.

Если присутствуют файлы, организованные в кластер, тогда операция 1504 завершается через ветвь YES. Операция 1508 определяет для каждого кластера местоположение подписи кластера. В одной реализации подпись каждого кластера находится в файле 210 подписи. В одной реализации файл 100 ресурсов информации о подписи декодируется для получения подписей кластеров. Операция 1512 определяет файлы, составляющие кластер. Эти файлы обычно находятся в файле подписи или в файле ресурсов информации безопасности.

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

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

Если отсутствуют какие-либо файлы, организованные в кластер, тогда операция 1504 завершается через ветвь NO. Операция 1520 определяет, образуют ли какие-либо файлы Веб-Страницу для варианта осуществления с децентрализованной архитектурой. Если операция 1520 завершается через ветвь YES, на операции 1524 декодируют каждую веб-страницу, чтобы определить, имеет ли веб-страница подпись или ссылку на подпись веб-страницы. Если веб-страница имеет подпись веб-страницы или ссылку на подпись веб-страницы, операция 1528 завершается через ветвь YES, и подпись читается на операции 1532. На этапе 1536 проверяется подпись. В одной реализации подпись проверяется путем извлечения (нахождения) соответствующих сертификатов и списков аннулирования, проверки статуса полученных сертификатов и списков аннулирования, применения нужных процедур преобразования к файлу, вычислению значения дайджеста файла, и сравнения значения дайджеста файла с дайджестом, присутствующим в файле подписи. Подписи также могут быть предоставлены уполномоченными. В одной реализации веб-страница включает в себя файл ресурсов информации о подписи, который декодируется для получения информации о подписи, такой как информация об уполномоченном, для облегчения проверки подписи. Если подписи предоставлены уполномоченными, проверяются ограничения уполномоченных.

Если операции 1520 и 1528 заканчиваются через ветвь NO, то оставшиеся файлы (если таковые присутствуют) рассматриваются как не имеющие подписи, так как не существует ссылка на цифровые подписи, не существует присоединенная цифровая подпись и файл не является компонентом кластера приложения. Клиентская операционная система обычно предупреждает пользователя, что файл не подписан или что подпись не действительна. Пользователь может решить, продолжить процесс инсталляции или нет. Операционная система может отвергнуть файл. Если требуется установить и запустить приложение автоматически, что является обычным для телевизионного приложения, тогда могут быть установлены стандарты, такие что неподписанное приложение не допускается к системным ресурсам. Это означает, что неподписанное приложение может быть способно отображать некоторые вещи на экране, но не будет способно выполнять более опасные операции, такие как доступ к локальному файлу и соединение с некоторым компьютером через Интернет. Обычно неподписанное приложение выполняется в "песочнице" (специальном механизме защиты) и только подписанные приложения могут выполнять действия вне "песочницы".

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

Возможны несколько других реализаций, включая следующие производные от Фиг.15: (1) Приложение может не исполнять операции с 1504 по 1516, так как это не включает в себя схему с централизованной подписью, (2) приложение может исполнять операции с 1520 по 1536 во время выполнения и не исполнять во время инициализации, (3) приложение может обрабатывать некоторые кластеры, применяя операции с 1504 по 1516 во время инициализации, но обрабатывать другие кластеры во время выполнения и только в случае необходимости.

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

Изобретение относится к защите дополнительного или интерактивного телевизионного контента (содержимого), а более конкретно к подписанию дополнительного или интерактивного телевизионного контента. Технический результат заключается в повышении безопасности телевизионного контента. Способ подписания приложения дополнительного телевизионного контента, являющегося набором файлов, содержащих программный код и ассоциированные объекты, включает в себя этапы: идентификацию по меньшей мере первой части (220₁-220_M, 220₁-220_V) файлов по меньшей мере в одном кластере файлов (214₁-214_N); вычисление подписи (211₁, 211_N) кластера для каждого кластера; и создание файла (100) ресурсов информации безопасности, который включает в себя описание (120, 120_А) местоположения подписи. 5 н. и 46 з.п. ф-лы, 16 ил., 1 табл.

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

идентификацию по меньшей мере первой части (220₁-220_M, 220₁-220_V) файлов по меньшей мере в одном кластере файлов (214₁-214_N);

вычисление подписи (211₁, 211_N) кластера для каждого кластера; и создание файла (100) ресурсов информации безопасности, который включает в себя описание (120, 120_А) местоположения подписи.

определение, что файлы упомянутого приложения организованы в кластер;

для каждого кластера:

обнаружение местоположения подписи каждого кластера;

обнаружение файлов, составляющих кластер; и

проверки целостности файлов в кластере при помощи операций, включающих в себя проверку подписи,

причем этап обнаружения местоположения подписи кластера содержит декодирование файла ресурсов информации безопасности для получения местоположения подписей кластера.

определение, что стартовый файл приложения имеет запись, которая включает в себя одно из:

ссылку на файл ресурсов информации безопасности, содержащее местоположение подписи, и файл ресурсов информации безопасности;

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

определение, составляют ли какие-либо файлы веб-страницы; и

если какие-либо из упомянутых файлов составляют веб-страницы, тогда

для каждой из упомянутых веб-страниц декодируют веб-страницы для обнаружения, содержит ли веб-страница одно из: ссылку на цифровую подпись и цифровую подпись,

чтение подписи, и

проверку подписи.

создают файлы (220₁-220_M, 220₁-220_V) приложения дополнительного телевизионного контента;

присоединяют по меньшей мере, одно из:

по меньшей мере, один файл (210₁, 210_N) подписи, имеющий подпись (211₁, 211_N) по меньшей мере части (214₁, 214_N) упомянутых файлов приложения, причем файл подписи создают отдельным от упомянутых файлов приложения; и стартовый файл (202, 302), имеющий одно из: файл (100) ресурсов информации безопасности, имеющий ссылку на каждый файл подписи, ссылку на файл ресурсов информации безопасности, имеющий ссылку на каждый файл подписи.

идентификацию по меньшей мере первой части (220₁-220_M, 220₁-220_V) файлов приложения дополнительного телевизионного контента в по меньшей мере одном кластере файлов (214₁, 214_N);

вычисление подписи (211₁, 211_N) кластера для каждого кластера файлов; и

создание файла (100) ресурсов информации безопасности, включающего в себя описание (120, 120_А) местоположения подписи.

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

для каждого кластера:

определение местоположения подписи файлов кластера, которые составляют кластер;

обнаружение файлов, составляющих кластер файлов; и

проверки целостности файлов в кластере при помощи операций, включающих в себя проверку подписи,

причем определение местоположения подписи файлов кластера содержит декодирование файла ресурсов информации безопасности для получения местоположения подписей кластера.

определение, что стартовый файл приложения имеет запись, которая включает в себя одно из:

ссылку на файл ресурсов информации безопасности, имеющий местоположение подписи, и этот файл ресурсов информации безопасности;

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

определение, что какие-либо файлы приложения дополнительного телевизионного контента составляют веб-страницы; и

если какие-либо из упомянутых файлов составляют веб-страницы, тогда

для каждой из этих веб-страниц, декодирование файла веб-страницы для определения, имеет ли веб-страница одно из: ссылку на цифровую подпись и цифровую подпись,

считывание подписи, и

проверку подписи.