RU2378773C2 - Подписание и проверка достоверности заголовков маршрутизации протокола инициирования сеанса - Google Patents

Abstract

Группа изобретений относится к средствам для подписания и проверки достоверности заголовков маршрутизации протоколов инициирования сеанса для аутентификации команд маршрутизации. Техническим результатом является повышение достоверности. Описываются способ, считываемый компьютером носитель, имеющий исполняемые компьютером инструкции, и считываемый компьютером носитель, на котором хранится структура данных для подписания и проверки достоверности заголовков маршрутизации протокола инициирования сеанса («SIP»). Узел SIP может принимать запрос SIP, включающий в себя заголовок сообщения. Могут генерироваться подпись, основанная на по меньшей мере части заголовка сообщения, и элемент заголовка узла SIP. Подпись затем может вставляться в элемент заголовка узла SIP. 4 н. и 8 з.п. ф-лы, 14 ил.

Description

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

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

Предпосылки создания изобретения

Протокол инициирования сеанса («SIP») представляет собой протокол сигнализации Интернета для установления, управления и завершения сеансов связи, включая мгновенный обмен сообщениями, телефонные вызовы по Интернету и видеоконференции по Интернету. SIP определен в запросе на комментарии и предложения 2543 и запросе на комментарии и предложения 3261 Целевой группы инженерной поддержки Интернета, каждый из которых включен в данную заявку посредством ссылки. Сеансы SIP включают в себя одного или нескольких участников или клиентов (обычно вызывающий абонент и вызываемый абонент). Сообщения SIP маршрутизируются между каждым оконечным узлом SIP (например, вызывающим абонентом и вызываемым абонентом) по сети узлов SIP, обычно различных серверов.

Существует, в основном, два типа сообщений SIP: запросы, которые посылаются от вызывающего абонента (например, оконечного узла SIP) вызываемому абоненту, и ответы, которые посылаются от вызываемого абонента вызывающему абоненту в ответ на запрос. В некоторых случаях вызываемый абонент также может посылать запрос вызывающему абоненту, после того как инициирован сеанс диалога. Каждое сообщение SIP, независимо от того, является ли оно ответом или запросом, включает в себя, в основном, три части: стартовую строку, заголовки и тело. Стартовая строка передает тип сообщения (например, запрос или ответ) и версию протокола, и тело сообщения включает в себя содержимое сообщения и может передавать информацию описания сеанса помимо сигнальной информации в стартовой строке. Поля заголовка SIP передают атрибуты сообщения и модифицируют смысл сообщения. Некоторые атрибуты сообщения, хранимые в полях заголовка, представляют собой инструкции в отношении того, как маршрутизировать сообщение, а также документировать фактический маршрут, проходимый сообщением. Например, каждый узел SIP, который управляет запросом на его маршруте, будет добавлять заголовок 'VIA' (через), содержащий информацию, идентифицирующую данный узел SIP, такой как полностью определенное доменное имя или адрес межсетевого протокола. Таким образом, могут быть обнаружены петли в маршрутах, и ответ использует заголовки VIA из запроса для определения маршрута прохождения для возврата к вызывающему абоненту. Однако конкретный путь сообщения не может быть фиксированным во времени, таким образом, узел SIP, такой как домашний сервер, может принимать первый запрос диалога, такой как телефонный вызов, но может не принимать последующие запросы в этом же диалоге. Чтобы оставаться «в цикле» данного диалога, узел SIP может вставить заголовок RECORD-ROUTE (записать маршрут), содержащий информацию, идентифицирующую его самого, такую как универсальный индикатор информационного ресурса («URI») или другой адрес, который позволяет другим серверам или конечным точкам достигать узла SIP. Части заполненного списка заголовков RECORD-ROUTE затем копируются принимающим конечным клиентом (вызываемым абонентом для запросов и вызывающим абонентом для ответов) в набор заголовков ROUTE (маршрут). Заголовки ROUTE SET (набор маршрутов) содержат данные, обеспечивающие инструкции узлам SIP в отношении того, как маршрутизировать любые будущие запросы в этом же сеансе диалога.

Сущность изобретения

Хотя поля заголовка SIP, описанные выше, способствуют маршрутизации сообщений на узлы SIP и от них, такие как серверы на маршруте сообщения, многие из этих заголовков не являются безопасными при использовании по стандартам SIP (RFC3261). Например, атаки типа «отказ в обслуживании» могут направляться на сервер с многочисленными ложными сообщениями SIP, включающими в себя поддельную информацию о маршруте в заголовке SIP. Истинный отправитель поддельного сообщения может маскироваться ложной информацией заголовка, возможно, производя впечатление, что атака типа «отказ в обслуживании» исходит от невиновного сервера. Кроме того, ложные заголовки маршрутизации могут создавать сообщения, циклически передаваемые между двумя серверами. Таким образом, каждый сервер на ложном «маршруте» поддельного сообщения может бесполезно расходовать ценные ресурсы для обработки и пересылки поддельных сообщений, таким образом отказывая в этих ресурсах законным пользователям.

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

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

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

Дополнительно или альтернативно, третья подпись может быть сгенерирована на основе по меньшей мере части заголовков RECORD-ROUTE заголовка сообщения. Третья подпись может быть вставлена в заголовок RECORD-ROUTE узла SIP. Когда вызываемый абонент отвечает на запрос SIP, заголовок RECORD-ROUTE узла SIP отражается обратно в заголовок ответа. Чтобы верифицировать целостность инструкций в отношении того, как маршрутизировать будущие запросы, третья подпись может быть верифицирована узлом SIP, когда узел SIP принимает ответ. Например, узел SIP, принимающий ответ, может идентифицировать заголовок RECORD-ROUTE, содержащий данные, отраженные из заголовка запроса, и извлекать подпись из отраженного заголовка. Узел SIP может генерировать подпись верификации, используя тот же процесс, что и используемый для генерирования третьей подписи, например генерирования подписи, основанной на по меньшей мере части заголовков в заголовке ответа. Узел SIP может затем сравнивать подпись верификации с извлеченной подписью. Если подписи совпадают, тогда сообщение может обрабатываться нормальным образом.

Четвертая подпись может быть сгенерирована и вставлена в заголовок ответа SIP. Например, узел SIP, принимающий ответ, может генерировать четвертую подпись, основанную на по меньшей мере части заголовков RECORD-ROUTE заголовка ответа и заголовка CONTACT заголовка ответа. Четвертая подпись аналогична второй подписи, описанной выше, однако, так как четвертая подпись генерируется на основе заголовка CONTACT в ответе, CONTACT идентифицирует вызываемого абонента, а не вызывающего абонента, как в случае с запросом. Четвертая подпись затем может быть вставлена в заголовок RECORD-ROUTE для узла SIP. Система вызывающего абонента, когда она принимает ответ, затем может сохранить части заголовка RECORD-ROUTE с присоединенной подписью в качестве заголовка ROUTE SET для использования и верификации инструкций по маршрутизации в последующих запросах.

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

Перечень чертежей

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

фиг.1 - принципиальная схема маршрута запроса INVITE (приглашение) и ответа между двумя клиентами протокола инициирования сеанса («SIP») согласно одному варианту выполнения изобретения;

фиг.2 - примерный запрос INVITE по фиг.1;

фиг.3 - примерный набор заголовков VIA по фиг.1;

фиг.4 - примерный набор заголовков RECORD-ROUTE по фиг.1;

фиг.5 - примерный ответ на запрос INVITE по фиг.2;

фиг.6 - примерный запрос, генерируемый узлом SIP вызываемого абонента по фиг.1;

фиг.7 - примерный запрос, генерируемый узлом SIP вызывающего абонента по фиг.1;

фиг.8 - схема примерного сервера SIP согласно одному варианту выполнения изобретения;

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

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

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

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

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

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

Подробное описание предпочтительного варианта выполнения

Атаки типа «отказ в обслуживании» обычно представляют собой компьютеризованные нападения, запускаемые злоумышленниками для перегрузки или останова сетевых служб, таких как Web-серверы или файловые серверы. Например, атака может вызвать то, что сервер станет настолько загруженным, пытаясь ответить на поддельные сообщения, что он игнорирует законные запросы на соединения. Альтернативно маршрутизация законных сообщений может быть нарушена и может вызывать неправильную пересылку ответов узлами SIP. В некоторых случаях протокол связи, используемый для передачи сообщений по компьютерной сети, может быть важной точкой для атаки. Например, как отмечено выше, поддельные сообщения SIP могут посылаться с ложными заголовками VIA, заголовками ROUTE и/или заголовками RECORD-ROUTE, таким образом направляя сообщения на страдающие от нападения узлы SIP и/или маскируя идентификационные данные и источник злоумышленника. Чтобы сократить такие атаки типа «отказ в обслуживании», инструкции по маршрутизации и фактические пути маршрутизации, содержащиеся в заголовках SIP, могут проверяться на достоверность для обеспечения их целостности.

На фиг.1 изображена примерная операция инициирования сеанса, при которой пользователь 100 (например, Алиса) клиента 102 SIP хочет инициировать сеанс связи с другим пользователем 400 (Бобом) по сети связи, которая может включать в себя Интернет, интрасеть, глобальную сеть, локальную сеть, виртуальную частную сеть и т.п. С этой целью клиент 102 SIP постоянно находящийся на компьютерной системе 104, посылает сообщение 500 с запросом INVITE, которое идентифицирует Боба в качестве предполагаемого получателя. В контексте связи по стандарту SIP клиент 102 SIP, который посылает сообщение 500 INVITE для инициирования сеанса, упоминается как «вызывающий абонент», и клиент 402 SIP на компьютерной системе 404 Боба упоминается как «вызываемый абонент». Как определено в SIP, клиент 102 SIP также называется «клиентом агента пользователя» («КАП»), так как он создает новый запрос, и клиент 402 SIP также называется «сервером агента пользователя» («САП»), так как он генерирует ответ 600 на запрос 500 SIP.

Как показано на фиг.1, сообщение 500 INVITE от Алисы посылается на сервер 200 исходящей связи для домена клиента SIP вызывающего абонента. После этого сообщение INVITE может проходить через многочисленные узлы SIP, включенные в операцию передачи сигналов, до того как оно достигнет прокси-сервера (сервера-посредника) 300 SIP домена Боба. Для простоты на фиг.1 изображено только пять узлов SIP, однако необходимо понять, что каждая линия связи может включать в себя другие серверы, шлюзы, мосты и т.п. Прокси-сервер 300 SIP направляет сообщение INVITE клиенту 402 SIP (вызываемому абоненту) компьютера Боба. Компьютер Боба может автоматически, или по разрешению от Боба, посылать ответ 600 на INVITE, такой как сообщение «200 (Все в порядке)», указывающее успешную передачу.

Как отмечено выше, каждое сообщение SIP, в общем случае, включает в себя стартовую строку, заголовок, содержащий информацию, касающуюся атрибутов и маршрутизации сообщения, и тело сообщения. Например, на фиг.2 изображено представление запроса 500 INVITE, посылаемого клиентом 102 SIP Алисы и принимаемого узлом 200 SIP. Примерный INVITE 500 включает в себя стартовую строку 502, множество заголовков 504 и тело 506. Стартовая строка 502 идентифицирует тип сообщения (в данном случае INVITE), запрашивающий URI, который, в основном, представляет собой адрес SIP вызываемого абонента, и версию SIP. Заголовки 504 представляют собой общепринятые поля по стандарту SIP. Заголовок 508 VIA содержит информацию, указывающую на протокол и адрес предыдущего сетевого сегмента. Заголовок 510 FROM (от кого) содержит информацию, указывающую на пользователя, отправляющего запрос (вызывающего абонента), в данном случае Алису. Заголовок 512 ТО (кому) содержит информацию, указывающую вызываемого абонента, задаваемого вызывающим абонентом. Заголовок 514 Call-ID (идентификатор вызова) содержит информацию, указывающую глобально уникальный идентификатор инициируемого сеанса. Заголовок 516 CSeq содержит информацию, указывающую идентификатор, который различает многочисленные сообщения, посылаемые с идентичными заголовками FROM, TO и Call-ID, как часть одной и той же транзакции. Заголовок 518 CONTACT содержит информацию, указывающую получателя для последующих запросов, позволяющую маршрутизации будущих сообщений обходить узлы SIP, не перечисленные в заголовках RECORD-ROUTE (дополнительно описанных ниже). Каждый из заголовка VIA, заголовка ТО, заголовка FROM, заголовка CONTACT, заголовка RECORD-ROUTE и заголовка ROUTE содержит данные, указывающие соответствующие маршрутизации местоположения в сети, такие как URI, адрес межсетевого протокола и т.п. Например, заголовок RECORD-ROUTE, содержащий данные, указывающие соответствующие маршрутизации местоположения, может включать в себя соответствующую часть URI, заключенную в скобки «< >», за которой следуют параметры заголовка. Соответствующая URI часть внутри скобок «< >» может включать в себя URI и параметр URI. В общих чертах, по меньшей мере одна пустая строка отмечает окончание заголовков 504 и начало части 506 тела. Примерный ответ 600, показанный на фиг.5, аналогично запросу INVITE, включает в себя стартовую строку 602, часть 604 заголовков и тело 606.

По стандарту SIP каждый узел SIP, который управляет INVITE 500, когда он проходит по сети, добавляет заголовок VIA к заголовку 504 INVITE. Таким образом, накопленные заголовки VIA могут использоваться вызываемым абонентом для направления маршрутизации ответа в ответ на запрос обратно вызывающему абоненту. Если узел SIP захочет продолжить управление сообщениями для этого конкретного диалога между вызывающим абонентом и вызываемым абонентом, узел SIP может вставить заголовок RECORD-ROUTE в заголовок 504 INVITE. Таким образом, чтобы направить маршрутизацию будущих запросов, которые могут генерироваться вызываемым абонентом, накопленные части URI заголовков RECORD-ROUTE и заголовка CONTACT для инициирующего диалог запроса могут быть сохранены принимающим вызываемым абонентом в качестве ROUTE SET заголовков в том же порядке, в котором они перечислены. Аналогично, чтобы предоставить инструкции по маршрутизации для будущих запросов, генерируемых вызывающим абонентом, накопленные части URI заголовков RECORD-ROUTE и заголовка CONTACT в ответ на инициирующий диалог запрос могут быть сохранены вызывающим абонентом в порядке, обратном порядку заголовков ROUTE SET.

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

Как показано на фиг.1, узлом 200 SIP может быть домашний сервер и он может принимать запрос INVITE от клиента 102 SIP. Узел 200 SIP, принимающий сообщение, вставляет заголовок VIA в заголовок 504 запроса INVITE. Узлу 200 SIP, в качестве домашнего сервера, может потребоваться управление любыми сообщениями SIP от клиента 102 SIP и на него. Следовательно, узел 200 SIP может вставлять заголовок RECORD-ROUTE в сообщение INVITE перед тем, как оно будет направлено на следующий узел SIP. В изображенном варианте выполнения по фиг.1 следующим узлом 250 SIP является пограничный сервер для клиента 102 SIP вызывающего абонента. Узел 250 SIP направляет сообщение INVITE после вставления своего собственного заголовка VIA и заголовка RECORD-ROUTE в заголовок 504 сообщения. В конечном счете сообщение INVITE маршрутизируется на узел 300 SIP, которым в изображенном варианте выполнения по фиг.1 является пограничный прокси-сервер клиента 402 SIP вызываемого абонента. Пограничным прокси-сервером может быть прокси-сервер, который предназначен для работы на границе сети, например, отделяя локальную сеть от Интернета. Аналогично пограничному серверу 250 пограничный прокси-сервер 300 вставляет заголовок VIA и заголовок RECORD-ROUTE в заголовок 504 INVITE перед пересылкой сообщения клиенту 402 SIP. Примеры заголовка 530 VIA узла 200 SIP, заголовка 532 VIA узла 250 SIP и заголовка 534 VIA узла 300 SIP, вставленных в запрос 500 INVITE, изображены на фиг.3. Примеры заголовка 520 RECORD-ROUTE узла 200 SIP, заголовка 522 RECORD-ROUTE узла 250 SIP и заголовка 524 RECORD-ROUTE узла 300 SIP, вставленных в сообщение 500 INVITE, изображены на фиг.4.

Узел 402 SIP Боба может принимать INVITE и может посылать ответ 600 «Все в порядке» в ответ на запрос INVITE. На фиг.5 изображен примерный ответ 600 от узла 402 SIP на сервер 300. По стандарту SIP многие поля заголовка, или по меньшей мере части полей заголовка, ответа 600 копируются или отражаются из принимаемого запроса. Эти отражаемые заголовки могут включать в себя, например, как определено по стандарту SIP, каждый заголовок VIA, заголовок FROM, заголовок TO, каждый заголовок RECORD-ROUTE, заголовок Call-ID и заголовок CSeq. Таким образом, ответ 600, показанный на фиг.5, иллюстрирует отражаемые заголовки. Конкретно заголовки 608, 630, 632, 634 VIA в ответе 600 идентичны заголовкам 508, 530, 532, 534 VIA в INVITE 500, принимаемым узлом 402 SIP вызываемого абонента. Аналогично заголовки 620, 622, 624 RECORD-ROUTE идентичны заголовкам 520, 522, 524 RECORD-ROUTE, генерируемым узлами SIP и принимаемым узлом 402 SIP вызываемого абонента. Сообщение с ответом затем маршрутизируется по сети, направляемое заголовками 608, 630, 632, 634 VIA на узел 102 SIP вызывающего абонента.

Узлы SIP, например узлы 300, 250, 200 SIP, обрабатывающие ответ, могут подтвердить целостность фактического маршрута, проходимого ответом, посредством проверки достоверности инструкций по маршрутизации, содержащихся в заголовках VIA. В одном варианте выполнения узел SIP может хранить информацию о маршруте, такую как заголовки 508, 530, 532 VIA, в базе данных для последующего доступа и использования для верификации заголовков 608, 630, 632 VIA. Альтернативно, для уменьшения объема памяти и нагрузок доступа на узел SIP узел SIP может генерировать подпись, основанную на по меньшей мере части по меньшей мере одного заголовка, который содержит данные, указывающие соответствующее маршрутизации местоположение в сети на маршруте сообщения. Например, подпись может основываться на всех заголовках, содержащих соответствующее маршрутизации местоположение в сети, или может основываться только на части данного заголовка, такой как URI, параметр URI, одноранговое полностью определенное доменное имя («FQDN») и т.п. Подпись может основываться на другой информации в дополнение к по меньшей мере одному заголовку, включающей в себя идентификатор соединения для соединения, по которому сообщение будет посылаться на следующий сетевой сегмент, отражаемый заголовок, заголовок TO, заголовок FROM, заголовок CONTACT, заголовок CALL-ID, заголовок CSeq и Branch-ID (идентификатор ветви). Подпись, основанная на по меньшей мере части по меньшей мере одного заголовка запроса, затем может быть перенесена в ответ и проверена на достоверность, когда ответ обрабатывается узлом SIP. Должна ли часть заголовка быть включена в подпись или нет, может зависеть от того, будет ли часть заголовка изменяться до того, как она будет верифицирована при помощи прокси-сервера SIP. Например, части заголовка, содержащие информацию, которая может быть удалена или изменена перед тем, как к ним будет осуществлен доступ для верификации подписи, не должны включаться в подпись. Необходимо понять, что любой или все из узлов SIP на маршруте сообщения SIP могут генерировать и хранить подпись верификации любым подходящим образом, включая тот, который описан в данном изобретении. Также необходимо понять, что заголовки сообщения SIP могут проверяться на достоверность соответствующим образом согласно факторам обеспечения безопасности и стандартам сети и узлов SIP, включая сохранение списка доверенных линий связи, соответствующих глобальной политике в отношении подписи, и подпись/проверку достоверности сообщений на/от конкретного домена. Например, чтобы реализовать список доверенных линий связи, каждый сервер может сохранять список линий связи, которые он считает доверенными. Таким образом, любое сообщение, передаваемое на/поступающее от доверенной линии связи, может не подписываться/проверяться на достоверность. Следовательно, сервер может проверять список доверенных линий связи перед генерированием/проверкой на достоверность подписи, чтобы удостовериться в том, что линия связи является недоверенной, например, не перечисленной в списке доверенных линий связи.

В одном примере подпись может быть сгенерирована на основе по меньшей мере одного заголовка VIA сообщения с запросом с использованием доступного сеансового ключа. Чтобы проверить достоверность маршрута, проходимого сообщением, узел SIP может генерировать подпись VIA, основанную на всех заголовках VIA или по меньшей мере всех заголовках VIA, принимаемых узлом SIP. Например, для сообщения 500 INVITE, показанного на фиг.1 и 2, узел 200 SIP может обеспечивать подпись VIA, основанную на заголовке 508 VIA, содержащем информацию, обозначающую клиента 102 SIP (Алису), посредством использования сеансового ключа, доступного для узла 200 SIP. Сгенерированная подпись VIA может быть сохранена в сообщении, переносимом в сообщение с ответом и затем проверяемом на достоверность при обратном прохождении сообщения через узел 200 SIP. Аналогично, узел 300 SIP может генерировать подпись VIA, основанную на принимаемых заголовках VIA, для последующей проверки на достоверность ответа, когда он принимается на узле 300 SIP. Чтобы подписать заголовки VIA, узел 300 SIP может генерировать подпись VIA, основанную на заголовке 508 VIA Алисы, заголовке 530 VIA узла 200 SIP и заголовке 532 VIA узла 250 SIP, используя доступный сеансовый ключ.

Необходимо понять, что любая подходящая комбинация заголовков VIA и другая информация заголовков может быть подписана для аутентификации инструкций по маршрутизации в заголовке 604 ответа. Например, подпись VIA может быть основана на части заголовков VIA в дополнение к частям заголовка TO, заголовка FROM или любого другого заголовка, который может быть отражен из заголовка 504 запроса в заголовок 604 ответа. Кроме того, подпись 550 VIA, вставленная в заголовок 504 запроса, может представлять собой любые данные или сигнал, указывающий на сгенерированную цифровую подпись. Например, хранимая подпись 550 может представлять собой предопределенное количество старших битов блоба сгенерированной подписи или может представлять собой целую цифровую подпись.

Чтобы гарантировать, что подпись VIA, сгенерированная во время обработки запроса INVITE, присутствует для верификации в ответе на узле SIP, сгенерированная подпись VIA может быть вставлена в отражаемый заголовок запроса INVITE. Например, подпись может быть вставлена в качестве параметра URI или параметра заголовка после стандартной информации о соответствующем маршрутизации местоположении. Таким образом, когда узел 402 SIP клиента генерирует заголовки 604 ответа, основанные на отражаемых заголовках запроса SIP, сгенерированные подписи автоматически переносятся из запроса в ответ. Следовательно, узел SIP, принимающий ответ, может проверять достоверность подписи, переносимой в заголовок ответа. Необходимо понять, что любой отражаемый заголовок или специальный заголовок, который отражается узлом SIP клиента, основываясь на предшествующем соглашении, может быть пригодным для хранения подписи для проверки достоверности узлом SIP.

Как показано на фиг.3, подпись VIA может быть вставлена в заголовок VIA узла SIP, генерирующего подпись. Например, узел 300 SIP может генерировать подпись 550 VIA, основанную на заголовках 508, 530, 532 VIA, принимаемых в запросе 500. Узел 300 SIP может вставлять подпись 550 VIA в заголовок 534 VIA узла 300 SIP. Как отмечено выше, заголовки VIA в заголовке запроса отражаются обратно в заголовки 604 ответа. Таким образом, когда узел 402 SIP формирует ответ 600, он может копировать информацию, содержащуюся в заголовке 534 VIA, в заголовок 634 VIA узла 300 SIP (фиг.1). При стандартной обработке SIP, так как заголовок VIA отражается, копируется стандартная информация VIA, а также любая информация, присоединенная в качестве параметра заголовка, такая как подпись 550 VIA.

Чтобы проверить достоверность принимаемой подписи 650 VIA, узел 300 SIP (фиг.1) может отделить и сохранить принимаемую подпись 650 VIA, показанную на фиг.5. Узел 300 SIP может генерировать подпись VIA проверки достоверности, используя те же процедуры, что и используемые для генерирования подписи 550 VIA, вставленной в запрос. Согласно генерированию подписи 550 VIA, описанной выше, узел 300 SIP может идентифицировать заголовки VIA в принимаемом ответе 600 и генерировать подпись VIA проверки достоверности, основанную на всех заголовках VIA, перечисленных ниже заголовка 534 VIA узла 300 SIP. Таким образом, подпись VIA проверки достоверности может основываться на тех заголовках VIA, которые были известны узлу 300 SIP, когда он генерировал подпись 550 VIA в сообщении 500 с запросом. Следовательно, подпись VIA проверки достоверности для узла 300 SIP может основываться на заголовке 632 SIP для узла 250 SIP, заголовке 630 VIA для узла 200 SIP и заголовке 608 VIA для узла 102 SIP вызывающего абонента. Узел 300 SIP может сравнивать подпись VIA проверки достоверности с принимаемой подписью 650 VIA.

Если подписи действительно совпадают, узел 300 SIP может продолжать нормальную обработку по стандарту SIP и направить ответ следующему узлу SIP, указанному в заголовках VIA заголовков 604 ответа. Если подписи не совпадают, узел 300 SIP может выбросить ответ 600 из своего стека обработки и/или послать сообщение об ошибке службе контроля узлов SIP (не показана) или любому соответствующему агенту контроля, если это поддерживается протоколом. Чтобы оценить выполнение обработки сообщений для совпадения подписей и/или обнаружения атак, узел 300 SIP может инкрементировать счетчик неудачных выполнений сравнения подписей для каждого отброшенного сообщения. Счетчик неудачных выполнений сравнения подписей может представлять собой любые данные или сигнал, указывающий на неудачи узла SIP при верификации подписей заголовков. Например, счетчик неудачных выполнений сравнения подписей может подсчитывать количество неудачных проверок достоверности подписей в течение некоторого периода времени. Счетчик неудачных выполнений сравнения подписей затем может быть сравнен с предопределенным пороговым значением неудачных проверок достоверности подписей для этого периода времени, таких как примерно 6 неудачных проверок достоверности подписей, примерно 10 неудачных проверок достоверности подписей или примерно 25 неудачных проверок достоверности подписей примерно за 1 секунду времени обработки сообщений. Когда счетчик выполнений превысит порог, узел SIP может уведомлять или предупреждать системного администратора-человека (включая передачу сообщений по электронной почте и/или пейджеру) и/или основанного на компьютере системного администратора, который может инициировать предопределенные действия, основанные на счетчике выполнений, включая, например, сброс сетевых соединений, маршрутизирующих неудачные сообщения, блокирование сети и/или очистку очередей сообщений.

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

Например, если запрос содержит только один заголовок VIA, например заголовок 508 VIA узла 102 SIP Алисы в запросе 500, подпись может не генерироваться в запросе на узле. Более конкретно, узлу 102 SIP Алисы может не потребоваться верификация каких-либо инструкций по маршрутизации в ответе 600, так как ответ будет использоваться узлом 102 SIP, например, он не будет пересылаться далее. Таким образом, подпись VIA может не генерироваться, когда запрос содержит только один заголовок VIA, и, соответственно, может не потребоваться верификация подписи VIA, когда принимаемый запрос содержит только 1 заголовок VIA, например заголовок VIA принимающего узла SIP.

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

Как показано на фиг.1, соединения 210, 212 между узлом 200 SIP и узлом 250 SIP могут быть доверенными соединениями, так как данные соединения могут считаться внутренними линиями связи между домашним сервером и пограничным сервером. Так как серверы могут иметь другие способы аутентификации трафика сообщений между серверами, линии 260, 262 связи между узлом 250 SIP и узлом 300 SIP могут представлять собой доверенные соединения; однако данные линии связи могут считаться недоверенными в некоторых случаях, особенно если другие способы аутентификации сервера считаются недостаточными. Линии 310, 312 связи между узлом 402 клиента и узлом 300 SIP могут представлять собой недоверенные соединения, так как сообщения SIP посылаются на/от узла SIP клиента. Следовательно, на узле SIP может проверяться достоверность любого трафика сообщений, принимаемого по недоверенному соединению, такому как линия 312 связи, для верификации целостности и/или аутентификации сообщения.

Если ответы, принимаемые по доверенным линиям связи, не будут проверяться на достоверность, тогда нет необходимости генерировать подпись VIA, когда запрос будет пересылаться на следующий узел SIP по доверенной линии связи. Например, узлы 200 и 250 SIP могут не принимать ответ 600 по недоверенному соединению, и поэтому эти узлы могут не генерировать или сохранять подпись VIA в заголовках 504 запроса INVITE, так как для них может отсутствовать необходимость проверять достоверность маршрута ответа. Следовательно, перед генерированием подписи VIA узел SIP может определить, требуется ли проверка достоверности соответствующего ответа. Если не требуется верификация ответа, например, следующая линия связи является доверенным соединением, тогда не требуется генерирование подписи VIA, и может продолжаться нормальная обработка запроса SIP. Однако, если соответствующий ответ будет приниматься на узле SIP по недоверенному соединению, тогда может быть сгенерирована подпись VIA, как описано выше. Аналогично, после приема ответа узел SIP может сначала определить, принимается ли ответ от недоверенного соединения. Если да, тогда может проверяться достоверность подписи VIA, если она присутствует. Например, узел 300 SIP может определить, принимается ли ответ 600 по недоверенному соединению. Как показано на фиг.1, линия 312 связи представляет собой недоверенное соединение. Как результат, узел 300 SIP может тогда идентифицировать заголовок 634 VIA узла 300 SIP в заголовке 604 ответа. Узел 300 SIP может определить, присутствует ли подпись в идентифицированном заголовке 634 VIA. Если подпись VIA не присутствует, узел 300 SIP может послать сообщение об ошибке, если это разрешено протоколом, может выбросить сообщение из своего стека обработки, может инкрементировать счетчик неудачных выполнений сравнения подписей и/или предпринять любое другое надлежащее действие. Если подпись 650 VIA присутствует, как показано на фиг.5, узел 300 SIP может верифицировать эту подпись, как описано выше.

Подписание заголовков VIA, как отмечено выше, может способствовать проверке целостности инструкций по маршрутизации в заголовке 604 ответа. Однако узел SIP может дополнительно или альтернативно потребовать проверку достоверности инструкций по маршрутизации для запроса, генерируемого вызываемым абонентом. Следовательно, узел SIP может генерировать подпись, основанную на по меньшей мере части по меньшей мере одного из заголовков RECORD-ROUTE инициирующего диалог запроса, и затем проверить достоверность данной подписи в последующем запросе от вызываемого абонента, чтобы гарантировать целостность инструкций по маршрутизации запроса в диалоге.

Чтобы гарантировать целостность маршрута, проходимого запросом вызываемого абонента, узел SIP может генерировать подпись ROUTE SET вызываемого абонента, основанную на соответствующих URI частях заголовков RECORD-ROUTE и заголовка CONTACT, содержащихся в принимаемых полях заголовков запроса. Если присутствует более одного заголовка CONTACT, подпись ROUTE SET вызываемого абонента может основываться на выбранных соответствующих URI частях заголовков RECORD-ROUTE и соответствующей URI части первого перечисленного заголовка CONTACT. Более конкретно, для сообщения 500 INVITE, показанного на фиг.1, 2 и 4, узел 300 SIP может обеспечивать подпись ROUTE SET вызываемого абонента, основанную на соответствующей URI части заголовка 522 RECORD-ROUTE узла 250 SIP, соответствующей URI части заголовка 520 RECORD-ROUTE узла 200 SIP и соответствующей URI части заголовка 518 CONTACT вызывающего абонента Алисы. Сгенерированная подпись ROUTE SET вызываемого абонента может быть сохранена в сообщении и перенесена на узел 402 SIP вызываемого абонента для хранения и использования в любых запросах, генерируемых узлом 402 SIP вызываемого абонента, которые принадлежат этому же диалогу. Необходимо понять, что любая подходящая комбинация заголовков RECORD-ROUTE и другая информация заголовков может быть подписана для аутентификации инструкций по маршрутизации для любого последующего запроса, генерируемого узлом 402 SIP вызываемого абонента. Подпись ROUTE SET вызываемого абонента, вставленная в заголовок 504 запроса, может представлять собой любые данные или сигнал, указывающий на сгенерированную подпись, включающую в себя предопределенное количество старших битов блоба подписи и полную цифровую подпись.

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

Как показано на фиг.2 и 4, подпись ROUTE SET вызываемого абонента может быть вставлена в качестве параметра URI в заголовок RECORD-ROUTE узла SIP, генерирующего подпись. Например, узел 300 SIP может генерировать подпись 560 ROUTE SET вызываемого абонента, основанную на соответствующих URI частях заголовков 522, 520 RECORD-ROUTE и заголовка 518 CONTACT в запросе 500. Узел 300 SIP может вставлять подпись 560 ROUTE SET вызываемого абонента в заголовок 524 RECORD-ROUTE узла 300 SIP в качестве параметра URI. Как отмечено выше, соответствующие URI части заголовков RECORD-ROUTE и заголовка CONTACT инициирующего диалог запроса от вызывающего абонента сохраняются и отражаются узлом SIP вызываемого абонента в заголовки ROUTE для обеспечения инструкций по маршрутизации для любых будущих запросов, генерируемых вызываемым абонентом в диалоге. Таким образом, как показано на фиг.6, когда узел 402 SIP формирует запрос, он может копировать соответствующую URI часть заголовка 524 RECORD-ROUTE в заголовок 724 ROUTE узла 300 SIP по стандартной обработке SIP. Так как отражается соответствующая URI часть заголовка RECORD-ROUTE, копируется стандартная информация о маршруте, а также любые параметры URI, включая подпись 560 ROUTE SET вызываемого абонента.

Чтобы проверить достоверность принимаемой подписи 760 ROUTE SET вызываемого абонента по фиг.6, узел 300 SIP может отделить и сохранить принимаемую подпись 760 ROUTE SET вызываемого абонента. Узел 300 SIP может генерировать подпись ROUTE SET проверки достоверности, используя те же процедуры, что и используемые для генерирования подписи 560 ROUTE SET вызываемого абонента, вставленной в создающий диалог запрос, в данном случае INVITE. Согласно генерированию подписи 560 ROUTE SET вызываемого абонента, описанной выше, узел 300 SIP может идентифицировать заголовки RECORD-ROUTE в принимаемом запросе 700 и генерировать подпись ROUTE SET проверки достоверности, основанную на всех заголовках ROUTE, присутствующих в запросе, за исключением заголовков принимающего узла SIP. Таким образом, подпись ROUTE SET проверки достоверности может быть основана на тех заголовках RECORD-ROUTE и заголовке CONTACT, которые были известны SIP 300, когда он генерировал подпись 560 ROUTE SET вызываемого абонента в сообщении 500 запроса. Например, на схеме по фиг.1 подпись ROUTE SET проверки достоверности для узла 300 SIP может быть основана на заголовке 722 ROUTE узла 250 SIP, заголовке 720 ROUTE узла 200 SIP и заголовке 718 ROUTE, основанном на заголовке CONTACT, идентифицирующем узел 102 SIP вызывающего абонента. Узел 300 SIP может сравнивать подпись ROUTE SET проверки достоверности с принимаемой подписью 760 ROUTE SET вызываемого абонента. Если подписи не совпадают, узел 300 SIP может послать сообщение об ошибке, если это разрешено протоколом, удалить запрос 700 из своего стека обработки, инкрементировать счетчик неудачных выполнений сравнения подписей и/или предпринять любое другое соответствующее действие. Если подписи действительно совпадают, узел 300 SIP может продолжить нормальную обработку по стандарту SIP и направить запрос на следующий узел SIP, указанный в заголовках ROUTE заголовков 704 запроса.

В некоторых случаях подпись ROUTE SET вызываемого абонента может быть сгенерирована и/или проверена ее достоверность на каждом этапе маршрута, например на каждом узле SIP, обрабатывающем запрос. Однако, чтобы уменьшить вычислительную нагрузку на серверы узлов SIP, проверка достоверности запроса может выполняться только тогда, когда это требуется.

Например, если запрос не содержит никаких заголовков RECORD-ROUTE, например, даже текущий обрабатывающий узел SIP не добавил заголовок RECORD-ROUTE, тогда подпись ROUTE SET вызываемого абонента может не генерироваться. Более конкретно, если узел SIP, обрабатывающий запрос, не запросил оставаться «в цикле» для дальнейшей связи между вызываемым абонентом и вызывающим абонентом, тогда данному узлу SIP может не потребоваться верификация инструкций по маршрутизации в будущем принимаемом сообщении.

В другом примере, если запрос содержит заголовки RECORD-ROUTE, но не имеет ни одного заголовка CONTACT, тогда узлу SIP может не потребоваться проверка достоверности никакого ответа или запроса, отражающего эти заголовки RECORD-ROUTE. Это может иметь место в некоторых случаях, включая некоторые типы сообщений SIP ACK (подтверждение приема) и CANCEL (аннулирование). Более конкретно, если принимаемый запрос включает в себя по меньшей мере один заголовок RECORD-ROUTE и ноль заголовков CONTACT, тогда подпись ROUTE SET вызываемого абонента может не генерироваться, и может продолжаться нормальная обработка сообщения.

В дополнительном примере может проверяться достоверность сообщения, когда оно принимается по недоверенному соединению, так как запросы от недоверенных линий связи могут быть более вероятными источниками атак типа «отказ в обслуживании». Если не будет проверяться достоверность запросов от вызываемого абонента, принимаемых по доверенным линиям связи, тогда нет необходимости генерировать подпись 560 ROUTE SET вызываемого абонента, когда инициирующий диалог запрос от вызываемого абонента будет пересылаться на следующий узел SIP по доверенной линии связи. Например, как показано на фиг.1, узел 200 SIP будет принимать запрос 700 по доверенному соединению, или другими словами, узел SIP не будет принимать запрос 700 по недоверенному соединению. Поэтому данный узел может не генерировать или вставлять подпись ROUTE SET вызываемого абонента в заголовки 504 запроса INVITE, так как у него может не быть необходимости проверять достоверность маршрута любых запросов от вызываемого абонента. Следовательно, перед генерированием подписи ROUTE SET вызываемого абонента узел SIP может определить, требуется ли проверка достоверности любого запроса вызываемого абонента. Если не будет верифицироваться запрос вызываемого абонента, например, текущий запрос будет приниматься по доверенному соединению, тогда нет необходимости генерировать подпись ROUTE SET вызываемого абонента, и может продолжаться нормальная обработка запроса SIP. Однако, если запрос вызываемого абонента будет приниматься на узле SIP по недоверенному соединению, тогда может генерироваться подпись ROUTE SET вызываемого абонента, как описано выше. Аналогично, во время верификации подписи ROUTE SET вызываемого абонента обрабатывающий узел SIP может сначала определить, выполняется ли принимаемый запрос от вызываемого абонента по недоверенному соединению. Если да, тогда может проверяться достоверность подписи ROUTE SET вызываемого абонента, если она присутствует. Например, узел 300 SIP может определить, принимается ли запрос 700 по недоверенному соединению. Как показано на фиг.1, линия 312 связи представляет собой недоверенное соединение. В результате узел 300 SIP может тогда идентифицировать заголовок 724 ROUTE узла 300 SIP в заголовке 704 запроса 700, показанного на фиг.6. Узел 300 SIP может определить, присутствует ли подпись в идентифицированном заголовке 724 ROUTE, и верифицировать данную подпись, если она присутствует.

Узел SIP может дополнительно или альтернативно потребовать проверку достоверности инструкций по маршрутизации для запроса в диалоге, генерируемого вызывающим абонентом после инициирующего диалог запроса. Следовательно, узел SIP может генерировать подпись, основанную на по меньшей мере части по меньшей мере одного из заголовков RECORD-ROUTE ответа на инициирующий диалог запрос, и затем проверять достоверность данной подписи в последующем запросе от вызывающего абонента для обеспечения целостности инструкций по маршрутизации запроса.

Для гарантии целостности маршрута, подлежащего прохождению запросом вызывающего абонента, узел SIP может генерировать подпись ROUTE SET вызывающего абонента, основанную на соответствующих URI частях заголовков RECORD-ROUTE и заголовка CONTACT, содержащихся в полях заголовков принимаемого ответа. Если присутствует более одного заголовка CONTACT, подпись ROUTE SET вызывающего абонента может основываться на выбранных соответствующих URI частях заголовков RECORD-ROUTE и соответствующей URI части первого перечисленного заголовка CONTACT. Более конкретно, для сообщения 600 с ответом, показанного на фиг.1 и 5, узел 200 SIP может обеспечивать подпись ROUTE SET вызывающего абонента, основанную на соответствующей URI части заголовка 622 RECORD-ROUTE узла 250 SIP, соответствующей URI части заголовка 624 RECORD-ROUTE узла 300 SIP и соответствующей URI части заголовка 618 CONTACT вызываемого абонента Боба. Сгенерированная подпись ROUTE SET вызывающего абонента может быть сохранена в сообщении и перенесена на узел 102 SIP вызывающего абонента для хранения и использования в любых запросах, генерируемых узлом 102 SIP, которые принадлежат этому же диалогу. Необходимо понять, что любая подходящая комбинация заголовков RECORD-ROUTE и другая информация заголовков может быть подписана для аутентификации инструкций по маршрутизации в любом последующем запросе, генерируемом узлом 102 SIP вызывающего абонента. Подпись ROUTE SET вызывающего абонента, вставленная в заголовок 604 ответа, может представлять собой любые данные или сигнал, указывающий на сгенерированную цифровую подпись, включая предопределенное количество старших битов блоба подписи и всю цифровую подпись.

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

Как показано на фиг.5, подпись ROUTE SET вызывающего абонента может быть вставлена в заголовок RECORD-ROUTE узла SIP, генерирующего подпись. Например, узел 200 SIP может генерировать подпись 660 ROUTE SET вызывающего абонента, основанную на соответствующих URI частях заголовков 622, 624 RECORD-ROUTE и заголовка 618 CONTACT в ответе 600. Узел 200 SIP может вставлять подпись 660 ROUTE SET вызывающего абонента в заголовок 620 RECORD-ROUTE узла 200 SIP. Как отмечено выше, соответствующие URI части заголовков RECORD-ROUTE и заголовка CONTACT ответа на инициирующий диалог запрос сохраняются и отражаются узлом SIP вызывающего абонента в заголовки ROUTE для обеспечения инструкций по маршрутизации для любых будущих запросов, генерируемых вызывающим абонентом в диалоге. Таким образом, как показано в примерном запросе 800 по фиг.7, когда узел 102 SIP формирует последующий запрос в данном диалоге, он может копировать соответствующую URI часть заголовка 620 RECORD-ROUTE в заголовок 820 ROUTE узла 200 SIP согласно стандартной обработке SIP. Так как отражается соответствующая URI часть заголовка RECORD-ROUTE, копируется стандартная информация о маршруте, а также любые параметры URI, включая подпись 660 ROUTE SET вызывающего абонента.

Чтобы проверить достоверность принимаемой подписи 860 ROUTE SET вызывающего абонента по фиг.7, узел 200 SIP может отделить и сохранить принимаемую подпись 860 ROUTE SET вызывающего абонента, показанную на фиг.7. Узел 200 SIP может генерировать подпись ROUTE SET проверки достоверности, используя те же процедуры, что и используемые для генерирования подписи 660 ROUTE SET вызывающего абонента, вставленной в ответ на создающий диалог запрос. В соответствии с генерированием подписи 660 ROUTE SET вызывающего абонента, описанной выше, узел 200 SIP может идентифицировать заголовки RECORD-ROUTE в принимаемом запросе 800 и генерировать подпись ROUTE SET проверки достоверности, основанной на всех заголовках ROUTE, присутствующих в запросе, за исключением заголовка ROUTE принимающего узла SIP. Таким образом, подпись ROUTE SET проверки достоверности может основываться на тех заголовках RECORD-ROUTE и заголовке CONTACT, которые были известны для SIP 200, когда он генерировал подпись 660 ROUTE SET вызывающего абонента в сообщении 600 с ответом. Следовательно, подпись ROUTE SET проверки достоверности для узла 200 SIP будет основываться на заголовке 822 ROUTE узла 250 SIP, заголовке 824 ROUTE узла 300 SIP и заголовке 818 ROUTE, основанном на заголовке CONTACT, идентифицирующем узел 402 SIP вызываемого абонента. Узел 200 SIP может сравнивать подпись ROUTE SET проверки достоверности с принимаемой подписью 860 ROUTE SET вызывающего абонента. Если подписи не совпадают, узел 200 SIP может послать сообщение об ошибке, если это поддерживается протоколом, удалить запрос 800 из своего стека обработки, инкрементировать счетчик неудачных выполнений сравнения подписей и/или предпринять любое другое надлежащее действие. Если подписи действительно совпадают, узел 200 SIP может продолжать нормальную обработку согласно стандарту SIP и направить запрос на следующий узел SIP, указанный в заголовках ROUTE заголовков 804 запроса.

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

Например, если ответ на запрос не содержит никаких заголовков RECORD-ROUTE, например, даже текущий узел SIP не добавил заголовок RECORD-ROUTE, тогда подпись ROUTE SET вызывающего абонента может не генерироваться. Более конкретно, если узел SIP, обрабатывающий ответ, не запросил оставаться «в цикле» для дальнейшей связи между вызывающим абонентом и вызываемым абонентом, тогда данному узлу SIP может не потребоваться верификация инструкций по маршрутизации в дальнейших сообщениях.

В другом примере, если ответ содержит заголовки RECORD-ROUTE, но не имеет ни одного заголовка CONTACT, тогда узел SIP может не требовать проверки достоверности никакого ответа или запроса, отражающего данные заголовки RECORD-ROUTE. Более конкретно, если принимаемый ответ включает в себя по меньшей мере один заголовок RECORD-ROUTE и ноль заголовков CONTACT, тогда подпись ROUTE SET вызывающего абонента может не генерироваться, и может продолжаться нормальная обработка.

В дополнительном примере может проверяться достоверность заголовков ROUTE SET запроса вызывающего абонента, когда они принимаются только по недоверенному соединению. Если не будет проверяться достоверность запросов, принимаемых по доверенным линиям связи, тогда нет необходимости генерировать подпись 660 ROUTE SET вызывающего абонента, когда ответ будет пересылаться на следующий узел SIP по доверенной линии связи. Аналогично, после приема запроса от вызывающего абонента нет необходимости проверять достоверность подписи ROUTE SET, если принимается по доверенному соединению.

Как отмечено выше, заголовки RECORD-ROUTE включены в инициирующий диалог запрос и его соответствующий ответ для генерирования заголовков ROUTE SET вызываемого абонента и вызывающего абонента, используемых для маршрутизации последующих запросов. Таким образом, в некоторых случаях узел SIP может проверять достоверность заголовков RECORD-ROUTE в ответе на инициирующий диалог запрос для гарантии целостности заголовков RECORD-ROUTE. Например, присоединяющий узел может подделать заголовки RECORD-ROUTE в запросе, и, следовательно, последующий узел SIP может выполнить подписывание по обманным заголовкам RECORD-ROUTE, таким образом приводя к заголовку ROUTE с достоверной подписью ROUTE SET, но основанной на обманной информации о маршруте. Следовательно, узел SIP может генерировать подпись, основанную на по меньшей мере части по меньшей мере одного из заголовков RECORD-ROUTE запроса, и затем проверять достоверность данной подписи в ответе от вызываемого абонента для гарантии целостности заголовков RECORD-ROUTE сообщения.

Для гарантии целостности набора заголовков RECORD-ROUTE узел SIP может генерировать подпись RECORD-ROUTE, основанную на соответствующих URI частях заголовков RECORD-ROUTE, содержащихся в полях заголовков принимаемого запроса. Более конкретно, для сообщения 500 INVITE, показанного на фиг.1, 2 и 4, узел 300 SIP может предусматривать подпись 570 RECORD-ROUTE, основанную на соответствующей URI части заголовка 522 RECORD-ROUTE узла 250 SIP и соответствующей URI части заголовка 520 RECORD-ROUTE узла 200 SIP. В противоположность подписи ROUTE SET вызываемого абонента, описанной выше, подпись 570 RECORD-ROUTE не включает в себя заголовок CONTACT, так как вызываемый абонент, по стандартам SIP, не будет отражать заголовок 518 CONTACT в ответе. Сгенерированная подпись 570 RECORD-ROUTE может быть сохранена в сообщении и перенесена в сообщение с ответом и может быть проверена ее достоверность, когда ответ обрабатывается при помощи узла SIP. Необходимо понять, что любая подходящая комбинация заголовков RECORD-ROUTE и другая информация заголовков может быть подписана для аутентификации инструкций по маршрутизации в ответе, генерируемом узлом 402 SIP вызываемого абонента. Подпись 570 RECORD-ROUTE, вставленная в заголовок 504 запроса, может представлять собой любые данные или сигнал, указывающие на сгенерированную цифровую подпись, включающую предопределенное количество старших битов блоба подписи и саму всю цифровую подпись.

Для гарантии того, что подпись RECORD-ROUTE, генерируемая во время обработки запроса, присутствует для верификации в ответе, генерируемом узлом 402 SIP вызываемого абонента, сгенерированная подпись 570 RECORD-ROUTE может быть вставлена в качестве или параметра заголовка, или параметра URI в отражаемый заголовок запроса. Таким образом, так как узел 402 SIP клиента генерирует ответ, основанный на отражаемых заголовках, из запроса SIP, сгенерированные подписи автоматически переносятся из запроса в ответ. Следовательно, узел SIP, принимающий ответ, может проверять достоверность подписи, переносимой в заголовок ответа. Необходимо понять, что любой отражаемый заголовок или специальный заголовок, который отражается узлом SIP клиента, основываясь на предшествующем соглашении, может быть пригодным для хранения подписи RECORD-ROUTE для проверки достоверности узлом SIP.

Как показано на фиг.4, подпись RECORD-ROUTE может быть вставлена в заголовок RECORD-ROUTE узла SIP, генерирующего подпись. Например, узел 300 SIP может вставлять подпись 570 RECORD-ROUTE в качестве параметра заголовка в заголовок 524 RECORD-ROUTE узла 300 SIP. Как отмечено выше, заголовки RECORD-ROUTE отражаются обратно в заголовки 604 ответа. Таким образом, когда узел 402 SIP формирует ответ, такой как ответ 600, показанный на фиг.5, он может копировать заголовок 524 RECORD-ROUTE в заголовок 624 RECORD-ROUTE узла 200 SIP согласно стандартной обработке SIP. Так как отражается заголовок RECORD-ROUTE, копируется стандартная информация, а также любые параметры заголовка, включая подпись 570 RECORD-ROUTE.

Чтобы проверить достоверность принимаемой подписи 670 RECORD-ROUTE по фиг.5, узел 300 SIP может отделить и сохранить принимаемую подпись 670 RECORD-ROUTE. Узел 300 SIP может генерировать подпись RECORD-ROUTE проверки достоверности, используя те же процедуры, что и используемые для генерирования подписи 570 RECORD-ROUTE, вставленной в соответствующий запрос, в данном случае INVITE. В соответствии с генерированием подписи 570 RECORD-ROUTE, описанной выше, узел 300 SIP может генерировать подпись RECORD-ROUTE проверки достоверности, основанную на соответствующей URI части заголовка 622 RECORD-ROUTE узла 250 SIP и соответствующей URI части заголовка 620 RECORD-ROUTE узла 200 SIP. Узел 300 SIP может сравнивать подпись RECORD-ROUTE проверки достоверности с принимаемой подписью 670 RECORD-ROUTE. Если подписи не совпадают, узел 300 SIP может послать сообщение об ошибке, если это поддерживается протоколом, удалить ответ 600 из своего стека обработки и/или инкрементировать счетчик неудачных выполнений сравнения подписей. Если подписи действительно совпадают, узел 300 SIP может продолжить нормальную обработку по стандарту SIP и направить ответ на следующий узел SIP, указанный в заголовках VIA заголовков 604 ответа.

В некоторых случаях может проверяться достоверность заголовков RECORD-ROUTE ответа на каждом этапе маршрута, например на каждом узле SIP, обрабатывающем ответ. Однако, чтобы снизить вычислительную нагрузку на узлы SIP, достоверность ответа может проверяться только тогда, когда это требуется, аналогично тому, как описано выше с ссылкой на подпись 650 VIA. Например, если запрос не содержит никаких заголовков RECORD-ROUTE, тогда подпись RECORD-ROUTE может не генерироваться. В дополнительном примере, если соединение на следующий узел SIP представляет собой доверенное соединение, тогда может не генерироваться подпись RECORD-ROUTE. Чтобы снизить нагрузку на системы связи, узел SIP может удалить подпись RECORD-ROUTE из заголовка RECORD-ROUTE после верификации и перед направлением ответа на следующий узел SIP.

Чтобы генерировать подпись, основанную на по меньшей мере части заголовков в сообщении SIP, узел SIP, требующий возможности проверки достоверности и верификации, может включать в себя криптографическую программу, которая исполняется на центральном процессоре, для выполнения конкретных криптографических функций, включая шифрование, расшифрование, подписание и/или верификацию. В качестве примера, криптографическая программа может выполнять генерирование и разрушение криптографических ключей, таких как симметричные ключи, которые используются для добавления случайных данных при вычислении подписи или используются для целей шифрования/расшифрования. Альтернативно, криптографическая программа может иметь доступ к паре асимметричных (открытый/секретный) ключей. В обычной паре асимметричных ключей открытый ключ может использоваться для шифрования информации, и соответствующий секретный ключ может использоваться для расшифрования информации. Цифровая подпись может быть сгенерирована с использованием секретного ключа, и эта подпись может быть аутентифицирована с использованием открытого ключа. Необходимо понять, что любой односторонний механизм хэширования может быть подходящим для генерирования подписей, основанных на заголовках SIP, включая или в отдельности, или в комбинации алгоритм сжатия сообщений 5 (MD5), привязку, хэшевый код аутентификации сообщений (HMAC), стойкий алгоритм хэширования 1 (SHA1) и алгоритм Ривеста-Шамира-Адлемана (RSA), основанные на многих факторах, таких как устойчивость к атаке, относительное быстродействие и вычислительная нагрузка, для генерирования ассоциированной подписи. Также необходимо понять, что весь блоб подписи, часть блоба подписи или кодированная версия блоба подписи, использующая любую схему кодирования, может быть вставлена в качестве подписи VIA, RECORD SET и/или RECORD-ROUTE. В одном примере подписью может быть 16-байтовый односторонний хэш MD5 выбранной части заголовков сообщения SIP и любой другой информации, включающей в себя случайное число и/или сеансовый ключ. Подпись, основанная на заголовках SIP, может быть сгенерирована с релевантными заголовками в любом конкретном порядке, до тех пор, пока данный порядок остается согласованным между генерированием и проверкой достоверности подписи.

Каждая из подписи VIA, подписей ROUTE SET и подписи RECORD-ROUTE, обрабатываемых одним и тем же узлом SIP, может быть сгенерирована посредством одного и того же сеансового ключа. Альтернативно, ключи с различной стойкостью и быстродействием могут использоваться для каждой подписи или любой комбинации подписей. Например, так как обычно сравнительно быстро верифицируются подпись VIA и/или подпись RECORD-ROUTE, например, в соответствующем ответе, ключ VIA, используемый для генерирования подписей VIA, может представлять собой довольно упрощенный ключ/криптографическое решение с довольно небольшой вычислительной нагрузкой. Однако, так как верификация заголовков ROUTE SET может продолжаться в течение всего диалога, ключ ROUTE SET может представлять собой усиленный ключ/криптографическое решение, которое менее уязвимо для атаки, чем упрощенный ключ/криптографическое решение.

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

Каждый узел SIP может генерировать свой собственный сеансовый ключ, такой как ключ VIA для генерирования подписей VIA, ключ ROUTE для генерирования заголовков ROUTE SET и ключ RECORD-ROUTE для генерирования подписей RECORD-ROUTE. Альтернативно, сеансовый ключ может быть доступен для каждого узла SIP, например при помощи сертификата для пары открытого/секретного ключей, так что каждый тип заголовка подписывается с использованием одного и того же ключа.

Чтобы снизить уязвимость сеансовых ключей, используемых для генерирования подписей, ключи время от времени могут обновляться. Например, сеансовый ключ может обновляться каждые 4 часа. Однако для гарантии того, чтобы диалоги могли продолжаться даже после обновления ключей, криптографическая программа узла SIP может хранить и поддерживать предыдущие сеансовые ключи. Хранимые ключи могут храниться в течение предопределенной продолжительности времени, такой как в диапазоне от примерно 5 минут до примерно 24 часов для ключей RECORD-ROUTE и ROUTE SET и в диапазоне от примерно 5 минут до примерно 30 минут для ключей VIA. Дополнительно или альтернативно сеансовые ключи могут сохраняться до того, как будут верифицированы все сообщения, подписанные с использованием данного ключа. Для гарантии того, что осуществляется доступ к правильному ключу для верификации подписи, криптографическая программа может вставить идентификатор ключа в подпись и/или присоединить идентификатор ключа в качестве дополнительного параметра в отражаемый заголовок SIP.

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

Например, узел 300 SIP может быть обеспечен пулом серверов, включающим в себя первый сервер 300А и второй сервер 300В, как показано пунктирной линией на фиг.1. В некоторых случаях запрос 500 может маршрутизироваться через узел 300А SIP, и последующие запросы 700 в диалоге от вызываемого абонента могут маршрутизироваться через узел 300В SIP. Следовательно, для верификации подписи 760 ROUTE SET в запросе в диалоге узлу 300В SIP необходимо знать ключ, используемый узлом 300А SIP для генерирования подписи 560 ROUTE SET. Как показано в примерных заголовках RECORD-ROUTE запроса по фиг.4, заголовок RECORD-ROUTE, такой как заголовок 534 RECORD-ROUTE, может включать в себя типовую информацию о местоположении в сети при стандартной обработке SIP, подпись 560 ROUTE SET, генерируемую узлом 300А SIP, и данные, представляющие ключ 580 ROUTE SET, используемый узлом 300А SIP для генерирования подписи 560.

Однако для гарантии того, что другие узлы SIP не имеют доступа к ключу 580 ROUTE SET в заголовке сообщения, узел 300А SIP может шифровать ключ ROUTE SET при помощи открытого ключа. Следовательно, чтобы верифицировать целостность данного шифрования, узел SIP может подписывать зашифрованный ключ ROUTE SET при помощи секретного ключа. Узел 300А SIP затем может вставить зашифрованный и подписанный сеансовый ключ в отражаемый заголовок, такой как параметр URI заголовка RECORD-ROUTE, для распространения безопасного сеансового ключа на сервер, имеющий доступ к паре открытого/секретного ключей, используемой для шифрования и подписания сеансового ключа. Зашифрованный сеансовый ключ и подписанный сеансовый ключ могут быть вставлены в качестве единственного параметра или многочисленных параметров.

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

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

Например, как показано на фиг.6, когда узел 300В SIP принимает запрос 700 с заголовком 724 ROUTE SET, содержащим подпись 760 ROUTE SET, узел 300В SIP может исследовать подпись ROUTE SET для идентификации того, какой ключ ROUTE SET использовался для генерирования подписи 560. В некоторых случаях узел 300В SIP может осуществлять доступ к базе данных хранимых ключей для верификации на предмет того, хранится ли в ней идентифицированный ключ 580 ROUTE SET. Если ключ ROUTE SET не хранится, тогда узел 300В SIP может осуществить доступ к паре открытого/секретного ключей для определения ключа ROUTE SET из заголовка ROUTE SET. Более конкретно, узел 300В SIP может использовать службу сертификатов для доступа к паре открытого/секретного ключей, или может извлечь пару открытого/секретного ключей из базы данных, или при помощи любого подходящего способа или процесса. Используя открытый ключ, узел 300В SIP может аутентифицировать подпись сеансового ключа. Узел 300В SIP также может использовать секретный ключ для расшифрования ключа 580 ROUTE SET и затем использовать данный расшифрованный сеансовый ключ для генерирования подписи ROUTE SET проверки достоверности. Аналогичным образом, сеансовые ключи, используемые для генерирования заголовков VIA и заголовков RECORD-ROUTE, могут быть вставлены в отражаемый заголовок и, в частности, могут быть вставлены в отражаемый заголовок, содержащий подпись, сгенерированную данным сеансовым ключом.

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

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

В комплексном примере, показанном на фиг.1, узел 300 SIP может генерировать подпись VIA и вставлять данную подпись в отражаемый заголовок, такой как параметр заголовка в заголовке VIA запроса 500. Затем может проверяться достоверность подписи VIA на узле 300 SIP, когда вызываемый абонент посылает ответ 600 на данный запрос. Аналогично, если запрос представляет собой инициирующий диалог запрос, узел 300 SIP может генерировать подпись RECORD-ROUTE и вставлять данную подпись в отражаемый заголовок, такой как параметр заголовка в заголовке RECORD-ROUTE запроса 500. Затем может проверяться достоверность подписи RECORD-ROUTE на узле 300 SIP, когда вызываемый абонент посылает ответ 600 на инициирующий диалог запрос. Кроме того, если запрос представляет собой инициирующий диалог запрос, узел 300 SIP также может генерировать подпись ROUTE SET вызываемого абонента и вставлять данную подпись в отражаемый заголовок, такой как параметр URI заголовка RECORD-ROUTE запроса 500. Данная подпись ROUTE SET может быть сохранена на узле SIP вызываемого абонента для использования в качестве набора заголовков ROUTE в любых будущих запросах, генерируемых вызываемым абонентом в данном диалоге. Таким образом, не проверяется достоверность подписи ROUTE SET вызываемого абонента до использования вызываемым абонентом в запросе. Аналогично, в ответе на инициирующий диалог запрос узел 200 SIP может генерировать подпись ROUTE SET вызывающего абонента и вставлять данную подпись в качестве параметра URI заголовка RECORD-ROUTE узла 200 SIP. Подпись ROUTE SET вызывающего абонента может сохраняться узлом SIP вызывающего абонента для использования в наборе заголовков ROUTE для любых запросов, генерируемых узлом SIP вызывающего абонента. Таким образом, подпись ROUTE SET вызывающего абонента может не верифицироваться до тех пор, пока она не будет передана в запросе от вызывающего абонента.

Ниже описывается примерная реализация сервера узла SIP со ссылкой на фиг.8-14.

Любая комбинация узла 102 SIP вызывающего абонента, узла 200 SIP, узла 250 SIP, узла 300 SIP и/или узла 402 SIP вызываемого абонента, изображенных на фиг.1, может присутствовать и работать на одном или нескольких компьютерах или других устройствах, действующих в качестве процессора узла SIP. Каждый из этих узлов может быть предусмотрен полностью или частично на многочисленных компьютерных системах или других устройствах и/или они могут быть объединены в сеть с использованием любого способа, известного из уровня техники, включая проводное соединение, беспроводное соединение и т.п. для гарантии процессов, описанных выше.

В изображенном варианте выполнения узел 300 SIP обеспечивается сервером 1300 узла, который описан ниже с ссылкой на фиг.8-14. Узел 102 SIP, узел 250 SIP, узел 200 SIP и узел 402 SIP могут быть обеспечены аналогичными серверными/компьютерными системами.

Как показано на фиг.8, сервер 1300 узла может включать в себя один или несколько портов 1302 связи, которые могут включать в себя один или несколько процессоров 1304, внутренний задающий генератор 1306 даты и времени и запоминающее устройство 1308, которое включает в себя одну или несколько компьютерных программ 1322, определяющих инструкции, которые, когда они исполняются, предписывают компьютеру выполнить операции узла 300 SIP. Запоминающее устройство также может включать в себя базу 1310 данных ключей, которая ниже подробно описывается в связи с фиг.9, и программы 1322 будут дополнительно описаны ниже в отношении фиг.10-14.

На фиг.9 изображена примерная таблица 1350 для базы 1310 данных ключей, которая включает в себя одну или несколько записей 1352. В общих чертах, каждая запись ассоциирует сеансовый ключ 1354 с дополнительной информацией о ключе. В данном примере каждая запись 1352 включает в себя идентификатор 1353 ключа, сеансовый ключ 1354, зашифрованный ключ 1356, который шифруется при помощи открытого ключа, дату/время создания 1358 и дату/время истечения 1360 срока действия. Узел 300 SIP может генерировать сеансовый ключ 1354; однако узел SIP может идентифицировать сеансовый ключ из самого сообщения, извлекать его из службы ключей или при помощи любого способа, подходящего для генерирования сеансового ключа, подлежащего использованию для подписания данных. Аналогично, остальные данные могут инициализироваться и обновляться, когда узел 300 SIP, само сообщение или другая система предоставляет информацию о ключе.

База данных ключей может быть базой данных любого вида, включая реляционную базу данных, объектно-ориентированную базу данных, неструктурированную базу данных, базу данных в памяти или другую базу данных. База данных может быть построена с использованием плоской файловой системы, такой как текст в формате Американского стандартного кода обмена информацией (ASCII), двоичный файл, данные, передаваемые по сети связи, или любой другой файловой системы. Несмотря на эти возможные реализации вышеупомянутых баз данных, термин «база данных», используемый в данной заявке, ссылается на любые данные, которые собираются и хранятся любым образом, доступным для компьютера.

Ссылаясь теперь на фиг.10-14, ниже описываются различные операции, выполняемые узлом 300 SIP. Более конкретно, генерирование подписи VIA описывается со ссылкой на фиг.10, и верификация подписи VIA описывается со ссылкой на фиг.11. Генерирование подписей RECORD-ROUTE и ROUTE SET описывается со ссылкой на фиг.12, и проверка достоверности этих подписей описывается со ссылкой на фиг.13. На фиг.14 изображаются операции импорта сеансового ключа с одного сервера на другой в пуле серверов.

Как показано на фиг.10, операции для генерирования подписи VIA включают в себя, но не в ограничительном смысле, прием 900 запроса SIP. Хотя вышеупомянутые фигуры описываются с ссылкой на запрос INVITE, подпись VIA может быть сгенерирована для всех запросов или выбранных запросов в зависимости от требований к безопасности и обработке системы. Узел SIP может определить 902, является ли линия связи, по которой будет направляться ответ, недоверенной линией связи. Если линия связи является доверенной, тогда узел SIP может продолжать стандартную обработку запроса по стандартным процессам SIP. Если направляющая ответ линия связи является недоверенной, операции могут включать в себя построение 904 набора заголовков VIA из всех принимаемых заголовков VIA по порядку за исключением заголовка VIA обрабатывающего узла. Конкретно, запрос может быть исследован, и заголовки VIA, присутствующие в принимаемом сообщении, могут быть сохранены в памяти сервера 1300. Если набор заголовков VIA является пустым (906), тогда может быть продолжена стандартная обработка сообщения. Если присутствует более одного заголовка VIA, операции также включают в себя идентификацию 908 ключа VIA, который, как отмечено выше, может генерироваться сервером 1300, доступ к которому осуществляется из самого сообщения (описано дополнительно ниже со ссылкой на фиг.14), или извлекаться из службы ключей при помощи средства, такого как Интернет. Подпись VIA затем может быть сгенерирована 910 и может включать в себя вызов криптографической программы для генерирования хэша набора заголовков VIA, хранимого в памяти. Может быть сгенерирован 912 заголовок VIA для обрабатывающего узла 300 SIP, и подпись VIA может быть вставлена 914 в качестве параметра заголовка в заголовок VIA для узла 300 SIP. Сервер 1300 может хранить 916 сеансовый ключ VIA в базе данных ключей, описанной выше с ссылкой на фиг.9, и может инициализировать или обновлять параметры ключа, такие как идентификатор ключа, дату/время создания ключа, дату/время истечения срока действия, зашифрованный ключ и/или другую информацию.

Как показано на фиг.11, после генерирования подписи VIA в запросе узел SIP может принимать 918 ответ в ответ на ранее обработанный запрос. Сервер может исследовать заголовки VIA ответа и определить 920, присутствует ли более одного заголовка VIA. Если присутствует только один заголовок VIA, тогда может продолжаться стандартная обработка сообщения. Если присутствует более одного заголовка VIA, тогда узел SIP может определить 922, был ли принят ответ по доверенному или недоверенному соединению. Если линия связи является доверенной, тогда может продолжаться стандартная обработка сообщения. Если линия связи является недоверенной, тогда узел 300 SIP может исследовать заголовок VIA для узла 300 SIP и определить 924, присутствует ли подпись. Если подпись не присутствует, тогда узел 300 SIP может выбросить сообщение из своих стеков обработки. Если подпись присутствует, узел 300 SIP может отделить подпись от заголовка и сохранить 926 подпись VIA в памяти и затем отделить 928 самый верхний заголовок VIA (например, заголовок VIA узла 300 SIP) из сообщения. Узел SIP может извлечь 930 соответствующий сеансовый ключ VIA из базы данных ключей, службы ключей или самого сообщения. Соответствующий ключ может быть выбран, основываясь на идентификаторе, явствующем из самой подписи, дате/времени сообщения, типе подписи (например, VIA) или любом другом параметре, подходящем для идентификации соответствующего сеансового ключа VIA. Узел SIP может генерировать 932 набор заголовков VIA из оставшихся заголовков VIA, присутствующих в ответе. Если подпись VIA была сгенерирована с заголовками VIA в порядке, данном в сообщении, верификация заголовка VIA может генерироваться в этом же порядке, чтобы обеспечить надлежащее упорядочение параметров подписи. Операции также включают в себя генерирование 934 подписи проверки достоверности VIA, основанной на наборе заголовков VIA и извлеченном сеансовом ключе, и затем сравнение 936 данной подписи VIA проверки достоверности с хранимой подписью VIA. Если подписи VIA совпадают, тогда может продолжаться стандартная обработка сообщения. Если данные подписи не совпадают, тогда узел SIP может выбросить сообщение из своего стека обработки или предпринять любое другое подходящее действие.

Как показано на фиг.12, операции для генерирования подписей ROUTE SET и RECORD-ROUTE включают в себя прием 938 сообщения на узле SIP и определение 940 того, содержит ли сообщение по меньшей мере один заголовок RECORD-ROUTE. Если сообщение не содержит никакого заголовка RECORD-ROUTE, тогда может продолжаться стандартная обработка сообщения. В противном случае, сервер SIP может определить 944, будет ли сообщение передаваться по доверенной или недоверенной линии связи. Более конкретно, сервер SIP может определить, будет ли сообщение, подлежащее проверке на достоверность, приниматься по доверенной или недоверенной линии связи. Если линия связи ответа является доверенной, тогда может продолжаться стандартная обработка. Если линия связи является недоверенной, тогда сервер SIP может определить 946, является ли принимаемое сообщение запросом. Если сообщение не является запросом, тогда сервер SIP может построить 948 набор заголовков RECORD-ROUTE, основываясь на заголовках RECORD-ROUTE в ответе. Если сообщение является запросом, тогда сервер SIP может построить 950 набор заголовков RECORD-ROUTE и идентифицировать 951 сеансовый ключ RECORD-ROUTE, который, как отмечено выше, может генерироваться сервером 1300, доступ к которому осуществляется из самого сообщения (описано дополнительно ниже с ссылкой на фиг.14), или извлекаться из службы ключей при помощи средства, такого как Интернет. Подпись RECORD-ROUTE затем может быть сгенерирована 952 и может включать в себя вызов криптографической программы для генерирования хэша соответствующих URI частей набора заголовков RECORD-ROUTE, хранимого в памяти. Подпись RECORD-ROUTE может быть вставлена 954 в качестве параметра заголовка в заголовок RECORD-ROUTE для узла 300 SIP. Сервер 1300 может хранить 956 сеансовый ключ RECORD-ROUTE в базе данных ключей, описанной выше со ссылкой на фиг.9, и может инициализировать и/или обновлять параметры ключа, такие как идентификатор ключа, дату/время создания ключа, дату/время истечения срока действия и/или зашифрованный ключ. Является ли или нет сообщение запросом, сервер SIP может определить 942, если имеется один заголовок CONTACT в принимаемом сообщении. Если нет, тогда может продолжаться стандартная обработка; в противном случае, узел SIP может построить 958 набор заголовков ROUTE из набора заголовков RECORD-ROUTE и заголовка CONTACT. Сервер SIP может затем идентифицировать 960 сеансовый ключ ROUTE SET и, используя данный ключ, может генерировать 962 подпись ROUTE SET, которая затем может быть вставлена 964 в качестве параметра URI в заголовок RECORD-ROUTE узла 300 SIP. Узел SIP может сохранить 966 сеансовый ключ ROUTE SET и параметры ключа в базе данных ключей, как описано выше. Сервер SIP затем может продолжить стандартную обработку сообщения.

Как показано на фиг.13, проверка достоверности подписи RECORD-ROUTE может происходить тогда, когда узел SIP принимает 968 ответ. Узел SIP может определить 970, присутствуют ли в сообщении какие-либо заголовки RECORD-ROUTE. Если нет, тогда может продолжаться стандартная обработка сообщения; в противном случае узел SIP может определить 972, был ли принят ответ по недоверенной линии связи. Если линия связи является доверенной, тогда может продолжаться стандартная обработка сообщения. Если линия связи является недоверенной, тогда узел SIP может определить 974, содержит ли заголовок RECORD-ROUTE для узла SIP подпись RECORD-ROUTE. Если нет, тогда сообщение может быть выброшено из стека обработки узла 300 SIP. Если присутствует подпись RECORD-ROUTE, тогда сервер узла SIP может отделить и сохранить 976 все подписи в заголовке RECORD-ROUTE узла 300 SIP. Например, заголовок RECORD-ROUTE для узла 300 SIP может содержать как подпись RECORD-ROUTE, так и подпись ROUTE SET. Любая из них может быть приведена первой в параметрах URI RECORD-ROUTE, поскольку их размещение согласованно по всему диалогу, и/или подписи идентифицируются соответствующим образом для различения многочисленных подписей. Например, каждая подпись, вставленная в заголовок с многочисленными подписями, может включать в себя идентификатор, задающий тип заголовка, и/или каждая подпись может сопровождаться дополнительным параметром, идентифицирующим тип вставленной подписи. Узел SIP может построить 978 набор заголовков RECORD-ROUTE, содержащий соответствующие URI части заголовков RECORD-ROUTE в заголовках сообщения. Узел SIP также может извлечь 980 соответствующий сеансовый ключ RECORD-ROUTE в соответствии с процедурами, описанными выше в отношении операции 930 по фиг.11. Узел SIP может генерировать 982 подпись RECORD-ROUTE проверки достоверности, основанную на наборе заголовков RECORD-ROUTE и сеансовом ключе, и затем сравнивать 984 подпись RECORD-ROUTE проверки достоверности с хранимой подписью RECORD-ROUTE. Если подписи не совпадают, тогда узел SIP может выбросить сообщение из своего стека обработки. Если подписи совпадают, тогда может продолжаться стандартная обработка. Если подпись ROUTE SET присутствовала в качестве параметра URI заголовка RECORD-ROUTE, сервер узла SIP может удалить 986 данную подпись из сообщения и/или памяти. Более конкретно, подписи ROUTE SET вызываемого абонента были сохранены узлом SIP вызываемого абонента и, таким образом, больше не требуются в настоящем сообщении, направляемом вызывающему абоненту. Для определения того, должна ли новая подпись ROUTE SET быть сгенерирована и передана вызываемому абоненту, узел SIP может определить 987, расположен ли следующий узел SIP через недоверенную линию связи и существует ли по меньшей мере один заголовок CONTACT. Если нет, тогда может продолжаться стандартная обработка сообщения. Если следующая линия связи является недоверенной, тогда сервер узла SIP может генерировать подпись ROUTE SET вызывающего абонента посредством извлечения 988 сеансового ключа ROUTE SET, который может быть тем же самым ключом, что и ключ RECORD-ROUTE. Используя данный ключ, узел SIP может генерировать 990 подпись ROUTE SET, основанную на наборе заголовков RECORD-ROUTE и соответствующей URI части первого перечисленного заголовка CONTACT. Подпись ROUTE SET может быть вставлена 992 в заголовок RECORD-ROUTE для узла 300 SIP, подлежащий переносу на узел 102 SIP вызывающего абонента. Узел SIP может сохранить 994 сеансовый ключ ROUTE SET и/или сеансовый ключ RECORD-ROUTE и параметры ключа в базе данных ключей, как описано выше. Сервер SIP затем может продолжить стандартную обработку сообщения. Проверка достоверности подписи ROUTE SET вызываемого абонента и/или подписи ROUTE SET вызывающего абонента в последующих запросах может повторять подобный процесс, как описано.

На фиг.14 изображены операции в одной примерной реализации для переноса сеансового ключа между серверами в пуле серверов. Например, как отмечено выше, узел 300 SIP может быть обеспечен сервером 300А и сервером 300В. Таким образом, узел 300А SIP может генерировать подпись с сеансовым ключом, и узел 300В SIP может быть тогда необходим для проверки достоверности данной подписи. Хотя нижеследующий пример описывается со ссылкой на заголовки ROUTE SET, подобный процесс может использоваться для шифрования, подписания и доступа к сеансовому ключу RECORD-ROUTE и/или сеансовому ключу VIA.

Как показано на фиг.14, общий сертификат пары открытого/секретного ключей может быть сгенерирован 996 и установлен 998 на каждом сервере (300А, 300В) в пуле серверов. Как отмечено выше, пара открытого/секретного ключей может использоваться для подписания и шифрования всех сеансовых ключей, обрабатываемых данным узлом, или каждый тип сеансового ключа (VIA, RECORD-ROUTE и/или ROUTE SET) может иметь отдельную пару открытых/секретных ключей. Во время работы узел 300А SIP может принимать 1000 запрос, который необходимо подписать. Как отмечено выше, сервер узла SIP может идентифицировать 1002 сеансовый ключ ROUTE SET посредством его генерирования, доступа к нему или его извлечения. Узел SIP также может верифицировать 1004, что сертификат сконфигурирован для маршрутизации информации, касающейся обмена ключами. Сервер SIP может определить отметку даты/времени создания сеансового ключа ROUTE SET и присоединить 1006 отметку даты/времени к сеансовому ключу. Используя открытый ключ, сервер SIP может шифровать 1008 сеансовый ключ и отметку даты/времени и подписывать 1010 результат при помощи секретного ключа. Результат зашифрованного и подписанного сеансового ключа может храниться 1012 в базе данных ключей, описанной выше со ссылкой на фиг.9, вместе с параметрами ключа, такими как отметка даты/времени, сеансовый ключ, идентификатор сеансового ключа и т.п. Используя сеансовый ключ ROUTE SET, узел SIP может генерировать подпись ROUTE SET, как описано выше со ссылкой на фиг.12, и генерировать 1014 заголовок RECORD-ROUTE для узла 300 SIP. Сервер узла SIP может вставлять 1018 подпись ROUTE SET в заголовок RECORD-ROUTE для узла SIP и также может вставлять 1020 подписанный и зашифрованный сеансовый ключ ROUTE SET в качестве параметров URI в заголовок RECORD-ROUTE узла SIP.

После того как вызываемый абонент примет запрос, он сохраняет соответствующие URI части заголовков RECORD-ROUTE и заголовка CONTACT в наборе заголовков ROUTE. Когда узел SIP вызываемого абонента генерирует последующий запрос в диалоге, узел SIP вызываемого абонента может включать в себя заголовки ROUTE SET, которые отражают заголовки RECORD-ROUTE и CONTACT, содержащие подпись ROUTE SET и сеансовый ключ ROUTE SET, генерируемые узлом 300А SIP. Второй узел 300В SIP может принимать 1022 запрос в диалоге с по меньшей мере одним заголовком ROUTE. Принимая во внимание извлечение 930 соответствующего сеансового ключа, описанное выше с ссылкой на фиг.12, узел SIP может извлекать 1024 подписанный и зашифрованный сеансовый ключ ROUTE SET из заголовка ROUTE и сравнивать 1026 подписанный и зашифрованный ключ с вводимыми данными в базу данных ключей для определения того, имеет ли серверный узел 300В доступ к расшифрованному сеансовому ключу. Если совпадение есть, узел 300В SIP может использовать сеансовый ключ из базы данных ключей для проверки достоверности подписи ROUTE SET в заголовке ROUTE. Если совпадения нет, узел SIP может извлекать 1028 подпись ключа и верифицировать 1030 подпись ключа при помощи открытого ключа. Если подпись не верифицируется, узел SIP может выбросить сообщение из своего стека обработки или предпринять любое другое подходящее действие. Если подпись не совпадает, может быть извлечен 1032 зашифрованный сеансовый ключ. Отметка даты/времени может расшифровываться 1034 отдельно от сеансового ключа, чтобы минимизировать ресурсы сервера, если ключ больше не является активным (например, истек срок действия). Более конкретно, узел SIP может проверять достоверность 1036 отметки даты/времени после расшифрования для верификации того, что отметка даты/времени находится в пределах продолжительности действия конфигурации для сеансового ключа данного типа. Если отметка даты/времени не может быть верифицирована, сообщение может быть выброшено из стека обработки. Если отметка даты/времени верифицируется, тогда сеансовый ключ может расшифровываться 1038 при помощи секретного ключа и затем использоваться для проверки достоверности 1040 подписи ROUTE SET. Результат расшифрованного сеансового ключа может сохраняться 1042 в базе данных ключей, описанной выше со ссылкой на фиг.9, вместе с параметрами ключа, такими как отметка даты/времени, подписанный и зашифрованный сеансовый ключ, идентификатор сеансового ключа и т.п. В некоторый момент времени может истекать срок действия сеансового ключа, и записи базы данных для данного сеансового ключа, включающие в себя сеансовый ключ, подписанный и зашифрованный сеансовый ключ и т.п., могут удаляться 1044 из базы данных ключей, так что когда завершен данный диалог, не ожидаются никакие другие заголовки, использующие данный сеансовый ключ, в конце активной продолжительности действия сеансового ключа и/или после его даты истечения срока действия.

Компьютерная система, с которой различные элементы узлов SIP по фиг.1 и/или 8 могут быть реализованы или индивидуально, или в комбинации, обычно включает в себя по меньшей мере один основной блок, подсоединенный как к устройству вывода, которое отображает информацию пользователю, так и к устройству ввода, которое принимает ввод от пользователя. Основной блок может включать в себя процессор, соединенный с системой памяти через механизм межсоединений. Устройство ввода и устройство вывода также подсоединены к процессору и системе памяти через механизм межсоединений.

Вычислительные устройства, изображенные на фиг.1 и/или 8, обычно включают в себя некоторый вид считываемого компьютером носителя. Считываемые компьютером носители могут быть любыми доступными носителями, к которым могут осуществить доступ другие вычислительные устройства на сервере SIP. В качестве примера, но не ограничения, считываемые компьютером носители могут содержать носители данных компьютера и среду передачи данных. Носители данных компьютера включают в себя энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные любым способом или по любой технологии, для хранения информации, такой как считываемые компьютером инструкции, структуры данных, программные модули или другие данные. Носители данных компьютера включают в себя, но не в ограничительном смысле, оперативное запоминающее устройство (ОЗУ, RAM), постоянное запоминающее устройство (ПЗУ, ROM), электрически стираемое программируемое ПЗУ (EEPROM), флэш-память или память другой технологии, компакт-диск, цифровой многофункциональный диск (DVD) или другое оптическое запоминающее устройство, магнитные кассеты, магнитную ленту, запоминающее устройство на магнитных дисках или другие магнитные запоминающие устройства, или любой другой носитель, который может использоваться для хранения требуемой информации, и к которому могут осуществить доступ вычислительные системы на узле SIP. Среда передачи данных обычно воплощает считываемые компьютером инструкции, структуры данных, программные модули и другие данные в модулированном данными сигнале, таком как несущая волна или другой транспортный механизм, и включает в себя любые данные в модулированном данными сигнале, таком как несущая волна или другой транспортный механизм, и включает в себя любые среды доставки информации. В качестве примера, но не ограничения, среда передачи данных включает в себя проводную среду, такую как проводная сеть или прямое проводное соединение, и беспроводную среду, такую как акустическая, радиочастотная (РЧ), инфракрасная и другая беспроводная среда. Комбинации любых из вышеприведенных сред и носителей также охватываются понятием «считываемый компьютером носитель».

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

Компьютерной системой может быть компьютерная система общего назначения, которая может программироваться с использованием языка программирования компьютеров, такого как SmallTalk, С++, Java, Ada или С# (Си-шарп), или других языков, таких как язык сценариев или даже язык ассемблера. Различные аспекты изобретения могут быть реализованы в непрограммируемой среде (например, документы, созданные на языке разметки гипертекста (HTML), расширяемом языке разметки (XML) или в другом формате, который при просмотре в окне программы браузера визуализирует аспекты графического интерфейса пользователя или выполняет другие функции). Различные аспекты изобретения могут быть реализованы в виде программируемых или непрограммируемых элементов, или любой их комбинации. Компьютерная система также может представлять собой специально программируемое аппаратное обеспечение специального назначения или специализированную интегральную схему (ASIC). Система считывателя также может включать в себя пейджер, телефон, персональный цифровой помощник или другое электронное устройство передачи данных.

В системе связи общего назначения процессором обычно является серийно выпускаемый процессор, такой как общеизвестный процессор Pentium®, имеющийся в наличии у Intel Corporation. Доступны многие другие процессоры. Такой процессор обычно исполняет операционную систему, которой может быть, например, Windows 95®, Windows 98®, Windows NT®, Windows 2000® или Windows XP®, имеющиеся в наличии у Microsoft Corporation, система MAC OS X, имеющаяся в наличии у Apple Computer, операционная система Solaris, имеющаяся в наличии у Sun Microsystems, или UNIX, имеющаяся в наличии у различных источников. Могут использоваться многие другие операционные системы.

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

Одна или несколько частей компьютерной системы могут быть распределены по одной или нескольким компьютерным системам (не показаны), соединенным с сетью связи. Эти компьютерные системы также могут представлять собой компьютерные системы общего назначения. Например, различные аспекты изобретения могут быть распределены по одной или нескольким компьютерным системам, сконфигурированным для предоставления услуги (например, серверы) одному или нескольким клиентским компьютерам, или для выполнения общей задачи в качестве части распределенной системы. Например, различные аспекты изобретения могут выполняться на системе клиент-сервер, которая включает в себя компоненты, распределенные по одной или нескольким серверным системам, которые выполняют различные функции согласно различным вариантам выполнения изобретения. Данные компоненты могут представлять собой исполняемый, промежуточный (например, промежуточный язык (IL)) или интерпретируемый (например, Java) код, который передается по сети связи (например, Интернету) с использованием протокола связи (например, SIP или протокола управления передачей/межсетевого протокола (TCP/IP)). Необходимо понять, что изобретение не ограничивается исполнением на любой конкретной системе или группе систем.

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

Claims (12)

1. Способ обработки сообщения протокола инициирования сеанса (SIP), содержащий этапы, на которых:
принимают запрос SIP на узле SIP, причем запрос SIP включает в себя заголовок сообщения, включающий в себя данные, указывающие соответствующие маршрутизации местоположения в сети;
определяют заголовок RECORD-ROUTE запроса SIP;
корректируют упомянутые данные на узле SIP;
генерируют подпись, основанную на по меньшей мере части заголовка сообщения, включающей в себя скорректированные данные;
генерируют элемент заголовка узла SIP; и
вставляют подпись в элемент заголовка узла SIP, при этом
при генерировании подписи подпись генерируют на основе по меньшей мере части заголовка RECORD-ROUTE запроса SIP и при вставлении подписи подпись вставляют в заголовок RECORD-ROUTE узла SIP.

2. Способ по п.1, в котором элемент заголовка узла SIP представляет собой отражаемый заголовок.

3. Способ по п.1, в котором при вставлении подписи подпись вставляют в качестве параметра заголовка в заголовке RECORD-ROUTE узла SIP.

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

5. Способ по п.1, дополнительно содержащий этапы, на которых:
определяют следующую линии связи на следующий узел SIP для приема запроса SIP; и определяют, является ли эта следующая линия связи на следующий узел SIP недоверенной линией связи, при этом при генерировании подписи подпись генерируют только тогда, когда следующая линия связи является недоверенной линией связи.

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

7. Способ обработки сообщения протокола инициирования сеанса (SIP), содержащий этапы, на которых:
принимают запрос SIP на узле SIP, причем запрос SIP включает в себя заголовок сообщения;
генерируют подпись, основанную на по меньшей мере части заголовка сообщения;
генерируют элемент заголовка узла SIP;
вставляют подпись в элемент заголовка узла SIP;
принимают ответ SIP в ответ на запрос SIP, причем ответ SIP включает в себя заголовок ответа;
генерируют еще одну подпись, основанную на заголовке RECORD-ROUTE и заголовке CONTACT заголовка ответа; и
вставляют эту еще одну подпись в заголовок RECORD-ROUTE узла SIP ответа; и перед генерированием упомянутой еще одной подписи удаляют существующую подпись из элемента заголовка узла SIP.

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

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

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

11. Считываемый компьютером носитель по п.8, в котором первое сообщение представляет собой сообщение протокола инициирования сеанса (SIP).

12. Считываемый компьютером носитель по п.8, в котором первый сервер представляет собой прокси-сервер.

Images