СПОСОБ АУТЕНТИФИКАЦИИ, СИСТЕМА, СЕРВЕР И КЛИЕНТ Российский патент 2012 года по МПК H04L9/32 

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

Настоящее изобретение относится к технологиям связи, в частности к способу аутентификации на основе протокола Синхронизации данных (DS) и протокола Управления устройством (DM), к системе, серверу и клиенту.

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

Язык разметки синхронизации (SyncML) является протоколом, разработанным для синхронизации личной информации и внутренних данных предприятия между несколькими платформами и сетями. Протокол SyncML задает последовательность операций между участвующими объектами и задает набор форматов сообщений для проведения таких операций. На основе SyncML Открытый альянс мобильной связи (OMA) разрабатывает протокол DS и протокол DM.

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

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

Аналогичный механизм аутентификации и безопасности применяется к протоколу DS и протоколу DM, чтобы эффективно аутентифицировать сервер и клиента, как показано на фиг.1:

Этап 101: Сервер отправляет клиенту Инициирующее сообщение для запуска сеанса.

Инициирующее сообщение содержит дайджест, сформированный с использованием случайного числа сервера (s_nonce), и инициирующую информацию (TriggerInfo). Инициирующее сообщение может передаваться в коротком сообщении или другом push-сообщении.

s_nonce является случайным числом (одноразовым номером), сформированным клиентом и доступным серверу.

Этап 102: Клиент отправляет запрос сеанса на сервер.

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

Запрос сеанса содержит SessionID и аутентификационную информацию (Authenticate) клиента. Аутентификационная информация является дайджестом, сформированным с использованием одноразового номера клиента (c_nonce).

c_nonce формируется сервером и доступен клиенту.

На этом этапе устанавливается сеансовое соединение между клиентом и сервером.

Этап 103: Сервер возвращает ответ, который содержит результат аутентификации и запрос аутентификации.

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

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

Этап 104: Клиент возвращает серверу сообщение, которое содержит результат аутентификации.

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

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

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

Если сервер знает, что s_nonce, используемый в Инициирующем сообщении, является неправильным, например если сервер не принимает никакого нормального ответа от клиента после повторной отправки Инициирующего сообщения, то сервер полагает, что s_nonce является неправильным и формирует дайджест Инициирующего сообщения, используя одноразовый номер по умолчанию "0x00000000". После неудачной аутентификации Инициирующего сообщения в соответствии с дайджестом, сформированным с использованием s_nonce, клиент использует одноразовый номер по умолчанию для формирования дайджеста и повторной аутентификации Инициирующего сообщения. Если аутентификация удается, то одноразовый номер по умолчанию используется, чтобы аутентифицировать сервер и клиента, и затем s_nonce и c_nonce обновляются. Процесс обновления показан на фиг.2.

Этап 201: Сервер отправляет клиенту Инициирующее сообщение для запуска сеанса.

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

Этап 202: Клиент неудачно аутентифицирует Инициирующее сообщение и использует одноразовый номер по умолчанию для повторной аутентификации.

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

Если аутентификация удается, то это указывает, что ранее использованный сервером s_nonce является неправильным, и клиент отправляет запрос сеанса на сервер.

Этап 203: Клиент отправляет запрос сеанса на сервер.

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

Запрос сеанса содержит SessionID и дайджест, сформированный с использованием одноразового номера по умолчанию.

Этап 204: Сервер возвращает ответ, который содержит результат аутентификации, запрос аутентификации и команду для обновления c_nonce.

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

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

Этап 205: Клиент возвращает серверу сообщение, которое содержит результат аутентификации и команду для обновления s_nonce.

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

Этап 206: Сервер возвращает клиенту результат обновления s_nonce.

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

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

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

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

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

Способ аутентификации на основе протокола DS или DM в варианте осуществления настоящего изобретения включает в себя:

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

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

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

Другой способ аутентификации на основе протокола DS или DM в варианте осуществления настоящего изобретения включает в себя:

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

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

Другой способ аутентификации на основе протокола DS или DM в варианте осуществления настоящего изобретения включает в себя:

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

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

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

Другой способ аутентификации на основе протокола DS или DM в варианте осуществления настоящего изобретения включает в себя:

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

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

Сервер, предоставленный в варианте осуществления настоящего изобретения, включает в себя:

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

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

Клиент, предоставленный в варианте осуществления настоящего изобретения, включает в себя:

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

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

Другой клиент, предоставленный в варианте осуществления настоящего изобретения, включает в себя:

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

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

Вышеупомянутое техническое решение эффективно повышает безопасность системы.

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

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

Фиг.1 - логическая блок-схема способа аутентификации в предшествующем уровне техники;

фиг.2 - логическая блок-схема использования одноразового номера по умолчанию для аутентификации и обновления s_nonce и c_nonce в предшествующем уровне техники;

фиг.3 - логическая блок-схема способа аутентификации в Варианте 1 осуществления настоящего изобретения;

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

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

фиг.6 - логическая блок-схема способа аутентификации в Варианте 2 осуществления настоящего изобретения;

фиг.7 - логическая блок-схема способа аутентификации в Варианте 4 осуществления настоящего изобретения;

фиг.8 - логическая блок-схема способа аутентификации в Варианте 5 осуществления настоящего изобретения;

фиг.9 - логическая блок-схема способа аутентификации в Варианте 6 осуществления настоящего изобретения;

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

фиг.11 - логическая блок-схема способа аутентификации в Варианте 8 осуществления настоящего изобретения;

фиг.12 - логическая блок-схема способа аутентификации в Варианте 9 осуществления настоящего изобретения;

фиг.13 - логическая блок-схема способа аутентификации в Варианте 10 осуществления настоящего изобретения;

фиг.14 показывает структуру системы аутентификации в Варианте 1 осуществления настоящего изобретения;

фиг.15 показывает структуру клиента в Варианте 1 осуществления настоящего изобретения;

фиг.16 показывает структуру клиента в Варианте 2 осуществления настоящего изобретения; и

фиг.17 показывает структуру системы аутентификации в Варианте 2 осуществления настоящего изобретения.

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

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

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

В способе аутентификации в Варианте 1 осуществления из настоящего изобретения сервер формирует одноразовый номер для Инициирующего сообщения, где одноразовый номер отличается от s_nonce и c_nonce и доступен Инициирующему сообщению. Одноразовый номер может называться одноразовым номером Инициирующего сообщения. Сервер использует этот одноразовый номер для формирования аутентификационной информации и отправляет клиенту новый одноразовый номер и аутентификационную информацию вместе с Инициирующим сообщением. Клиент использует новый одноразовый номер, чтобы аутентифицировать Инициирующее сообщение.

Как показано на фиг.3, способ аутентификации в Варианте 1 осуществления настоящего изобретения включает в себя следующие этапы.

Этап 301: Сервер отправляет клиенту Инициирующее сообщение. Сообщение содержит одноразовый номер Инициирующего сообщения.

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

В этом варианте осуществления существуют три типа способа использования одноразового номера Инициирующего сообщения.

(1) При формировании Инициирующего сообщения сервер использует свое системное время (Ts) в качестве одноразового номера Инициирующего сообщения и добавляет Ts в Инициирующее сообщение. Следовательно, после приема Инициирующего сообщения клиент может определить достоверность одноразового номера путем сравнения локального времени (Tc) с системным временем (Ts). Для одноразового номера его достоверность обычно называется свежестью одноразового номера. Свежий одноразовый номер является допустимым, а несвежий одноразовый номер является недопустимым.

После приема Инициирующего сообщения клиент вычисляет разницу между Ts и Tc, а именно |Ts-Tc|. Если |Ts-Tc| меньше заданной пороговой величины "Diff", то одноразовый номер Инициирующего сообщения является допустимым; если |Ts-Tc| не меньше заданной пороговой величины "Diff", то одноразовый номер Инициирующего сообщения является недопустимым.

Пороговая величина Diff обычно конфигурируется на клиенте и может быть эмпирическим значением, определенным в соответствии с сетевыми условиями. Поскольку сеть подвижной связи сама по себе неустойчива и стремится сформировать задержку передачи Инициирующего сообщения. Слишком малые пороговые величины имеют тенденцию сделать недопустимым одноразовый номер Инициирующего сообщения; если пороговая величина слишком большая, то в случае, когда сервер-злоумышленник многократно перехватывает Инициирующее сообщение и удерживает сообщение для клиента, клиент расценивает сообщения как допустимую информацию и обрабатывает их, поскольку |Ts-Tc| попадает в разброс пороговых величин. Большие пороговые величины более уязвимы для атак.

(2) Перед формированием Инициирующего сообщения сервер сначала формирует ID сеанса для Инициирующего сообщения в соответствии с некоторыми правилами. Правила делают возможным вывод ID предыдущего сеанса из ID текущего сеанса. ID сеанса служит в качестве одноразового номера Инициирующего сообщения. Сервер использует одноразовый номер для формирования дайджеста и использует дайджест для формирования Инициирующего сообщения.

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

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

В этом способе ID сеанса может быть заменен ID инициирующего сообщения (NotificationID). Этот ID инициирующего сообщения ассоциирует результат обработки Инициирующего сообщения, возвращенный клиентом, с Инициирующим сообщением.

(3) При формировании Инициирующего сообщения сервер нумерует каждое Инициирующее сообщение и использует номер в качестве исключительного одноразового номера Инициирующего сообщения. Сервер использует одноразовый номер для формирования дайджеста и использует дайджест для формирования Инициирующего сообщения.

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

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

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

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

Например, сервер последовательно отправляет 3 Инициирующих сообщения для 3 разных сеансов. Одноразовый номер Инициирующего сообщения, используемый 3 Инициирующими сообщениями, равен 30, 31 и 32 соответственно. Однако из-за неустойчивости сетей подвижной связи клиент сначала принимает Инициирующее сообщение, чей одноразовый номер равен 32. Следовательно, клиент определяет это сообщение как допустимое и записывает этот одноразовый номер. Когда к клиенту поступают другие два Инициирующих сообщения, клиент сравнивает их одноразовый номер с записанным одноразовым номером. Так как их одноразовый номер меньше записанного одноразового номера, клиент по ошибке определяет сообщения как недопустимые.

Для таких проблем варианты осуществления настоящего изобретения предлагают три решения.

Решение 1: Клиент сохраняет значения одноразовых номеров всех Инициирующих сообщений или одноразовый номер последнего принятого Инициирующего сообщения и сравнивает одноразовый номер Инициирующего сообщения, определенный как недопустимый, с сохраненным одноразовым номером. Если одноразовый номер отличается от сохраненного одноразового номера, то клиент определяет одноразовый номер как допустимый и сохраняет одноразовый номер.

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

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

Например, предполагается, что начальное значение равно 1, режим нумерации является возрастающим порядком, и клиент последовательно принимает эти значения одноразовых номеров Инициирующих сообщений: 1, 2, 4, 5 и 7. В этом случае клиент записывает максимальный одноразовый номер "7" и значения одноразовых номеров, которые меньше 7 и не были приняты, а именно "3" и "6". Когда клиент принимает одноразовый номер "6" Инициирующего сообщения, клиент сравнивает "6" с максимальным значением "7". Так как 6 меньше 7, то одноразовый номер является недопустимым. Затем клиент сравнивает "6" с "3" и "6" и обнаруживает одинаковое значение, и поэтому клиент определяет, что одноразовый номер Инициирующего сообщения является допустимым и удаляет записанный "6". В случае, если режим нумерации является убывающим порядком, способ оценки аналогичный и больше здесь не повторяется.

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

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

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

Trigger-hdr включает в себя version (версия), режим взаимодействия с пользователем (ui-mode), инициатора сеанса, одноразовый номер, зарезервированное поле (future-use), ID сеанса, длину идентификатора сервера (length-identifier) и идентификатор сервера.

К тому же варианты осуществления настоящего изобретения предоставляют два способа использования одноразового номера Инициирующего сообщения для формирования дайджеста:

Способ 1: Пусть H=хэш-функция MD5, а b64=кодирующая функция Base64. Дайджест может быть выражен в виде:

Дайджест=H(B64(H(server-identifier:password)):nonce:B64(H(trigger))),

где поле server-identifier является идентификатором сервера, поле password является паролем сервера, поле nonce является одноразовым номером Инициирующего сообщения (а именно, системным временем (Ts) или ID сеанса, либо номером Инициирующего сообщения, упомянутым выше), и поле trigger включает в себя trigger-hdr и trigger-body у Инициирующего сообщения.

После приема Инициирующего сообщения и определения, что одноразовый номер Инициирующего сообщения, переданный в Инициирующем сообщении, является допустимым, клиент ищет по дереву управления клиентом пароль, соответствующий серверу. Клиент использует найденный пароль, server-identifier в Инициирующем сообщении, nonce и Trigger для формирования дайджеста и сравнивает сформированный дайджест с дайджестом, переданным в сообщении. Если дайджест является таким же, то аутентификация удается; в противном случае аутентификация терпит неудачу.

Способ 2: Пусть H=хэш-функция MD5, а b64=кодирующая функция Base64.

Поскольку одноразовый номер Инициирующего сообщения передается в заголовке сообщения или теле сообщения, одноразовый номер становится частью поля trigger-hdr и поля trigger-body в Инициирующем сообщении. Поэтому для вычисления дайджеста нужно использовать только поле trigger-hdr и поле trigger-body. Дайджест может быть выражен в виде:

Дайджест=H(B64(H(server-identifier:password)):B64(H(trigger))),

где поле server-identifier является идентификатором сервера, поле password является паролем сервера и поле trigger включает в себя trigger-hdr и trigger-body Инициирующего сообщения.

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

Этап 302: Клиент определяет, что информация является допустимой, успешно аутентифицирует информацию и затем отправляет запрос сеанса на сервер.

После приема Инициирующего сообщения клиент оценивает, является ли допустимым одноразовый номер Инициирующего сообщения, переданный в Инициирующем сообщении. Способ оценки описывается выше. При определении, что одноразовый номер Инициирующего сообщения является допустимым, клиент ищет по дереву управления клиентом пароль, соответствующий серверу. Клиент использует найденный пароль, server-identifier в Инициирующем сообщении и Trigger для формирования дайджеста и аутентифицирует Инициирующее сообщение. Подробный способ аутентификации описывается на этапе 301. Способ аутентификации клиента меняется в зависимости от способа формирования дайджеста.

После того, как удается аутентификация, клиент отправляет запрос сеанса на сервер, чтобы начать сеанс.

Запрос сеанса содержит: SessionID и аутентификационную информацию (Authenticate), которая включает в себя дайджест, сформированный с использованием c_nonce.

На этом этапе устанавливается сеансовое соединение между клиентом и сервером.

Этап 303: Сервер возвращает ответ, который содержит результат аутентификации и запрос аутентификации.

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

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

Этап 304: Клиент возвращает серверу сообщение, которое содержит результат аутентификации.

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

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

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

Способ 1: Сервер время от времени обновляет свой пароль в учетной записи на клиенте. Сервер и клиент могут сбрасывать значение одноразового номера автоматически, когда сервер обновляет свой пароль в учетной записи на клиенте.

Способ 2: Когда нужно скорректировать одноразовый номер (например, когда наступает заданное время или отсчет достигает заданного значения), сервер выдает команду для сброса одноразового номера. Команда может быть командой Alert, например:

<Alert>

<CmdID>1</CmdID>

<Data>1227</Data> <!-заменить отсчет одноразового номера-->

</Alert>

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

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

<X>/AppAuth/<X>/SNAAuthCount

Впоследствии, когда нужно скорректировать одноразовый номер (например, когда наступает заданное время или отсчет достигает заданного значения), сервер выдает узлу команду Replace. Пример команды выглядит следующим образом:

<Replace>

<CmdID>4</CmdID>

<Item>

<Target>

<LocURI>./DMAcc/serverA/AppAuth/1/SNAAuthCount</LocURI>

</Target>

<Data>1</Data>

</Item>

</Replace>

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

Способ 4: Когда нужно скорректировать одноразовый номер (например, когда наступает заданное время или отсчет достигает заданного значения), клиент отправляет серверу запрос Replace. После того, как клиент принимает подтверждение от сервера, обе стороны корректируют одноразовый номер. После завершения корректировки сервер обновляет его пароль в учетной записи на клиенте, соответственно предотвращая перехват сообщения и атаки серверами-злоумышленниками.

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

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

Этап 501: Сервер отправляет клиенту Инициирующее сообщение. Сообщение содержит одноразовый номер Инициирующего сообщения.

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

Этап 502: Клиент определяет, что одноразовый номер Инициирующего сообщения, переданный в Инициирующем сообщении, является допустимым, успешно аутентифицирует сообщение и потом отправляет запрос сеанса на сервер.

После приема Инициирующего сообщения клиент оценивает, является ли допустимым одноразовый номер Инициирующего сообщения, переданный в Инициирующем сообщении. Способ оценки описывается выше. При определении, что одноразовый номер Инициирующего сообщения является допустимым, клиент ищет по дереву управления клиентом пароль, соответствующий серверу. Клиент использует найденный пароль, server-identifier в Инициирующем сообщении и Trigger для формирования дайджеста и аутентифицирует Инициирующее сообщение. Подробный способ аутентификации описывается на этапе 301. Способ аутентификации клиента меняется в зависимости от способа формирования дайджеста.

После того, как удается аутентификация, клиент отправляет запрос сеанса на сервер, чтобы начать сеанс.

Запрос сеанса содержит SessionID и аутентификационную информацию (Authenticate), которая включает в себя дайджест, сформированный с использованием c_nonce.

На этом этапе устанавливается сеансовое соединение между клиентом и сервером.

Этап 503: Сервер возвращает ответ, который содержит результат аутентификации и запрос аутентификации.

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

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

Этап 504: Клиент использует сохраненный s_nonce, чтобы аутентифицировать сервер, но аутентификация терпит неудачу.

Этап 505: Клиент отправляет серверу Сообщение опознавательного вызова и сообщение обновления s_nonce.

Этап 506: Сервер использует новый s_nonce для формирования аутентификационной информации и снова отправляет клиенту запрос аутентификации.

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

Этап 507: Клиент возвращает серверу сообщение, которое содержит результат аутентификации.

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

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

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

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

Этап 601: Сервер отправляет клиенту Инициирующее сообщение. Сообщение содержит s_nonce.

Этап 602: Сервер обнаруживает, что аутентификация терпит неудачу.

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

Этап 603: Сервер отправляет клиенту новое Инициирующее сообщение. Сообщение содержит одноразовый номер Инициирующего сообщения.

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

Этап 604: Клиент определяет, что одноразовый номер Инициирующего сообщения, переданный в Инициирующем сообщении, является допустимым, успешно аутентифицирует сообщение и потом отправляет запрос сеанса на сервер.

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

Способом оценки является Клиент оценивает, использует ли Инициирующее сообщение одноразовый номер Инициирующего сообщения, путем оценивания того, включает ли в себя Инициирующее сообщение поле nonce. То есть, если Инициирующее сообщение включает в себя поле nonce, то Инициирующее сообщение использует одноразовый номер Инициирующего сообщения. В качестве альтернативы клиент оценивает, использует ли Инициирующее сообщение одноразовый номер Инициирующего сообщения путем оценивания информации поля version в Инициирующем сообщении. Это происходит потому, что версия сообщения показывает, использует ли сообщение одноразовый номер Инициирующего сообщения.

После приема Инициирующего сообщения клиент оценивает, является ли допустимым одноразовый номер Инициирующего сообщения, переданный в Инициирующем сообщении. Способ оценки описывается выше. При определении, что одноразовый номер Инициирующего сообщения является допустимым, клиент ищет по дереву управления клиентом пароль, соответствующий серверу. Клиент использует найденный пароль, server-identifier в Инициирующем сообщении и Trigger для формирования дайджеста и аутентифицирует Инициирующее сообщение. Подробный способ аутентификации описывается на этапе 301. Способ аутентификации клиента меняется в зависимости от способа формирования дайджеста.

После того, как удается аутентификация, клиент отправляет запрос сеанса на сервер, чтобы начать сеанс.

Запрос сеанса содержит SessionID и аутентификационную информацию (Authenticate), которая включает в себя дайджест, сформированный с использованием c_nonce.

На этом этапе устанавливается сеансовое соединение между клиентом и сервером.

Этап 605: Сервер возвращает ответ, который содержит результат аутентификации и запрос аутентификации.

Этот этап аналогичен этапу 503 и больше не описывается здесь подробно.

Этап 606: Клиент использует сохраненный s_nonce, чтобы аутентифицировать сервер, но аутентификация терпит неудачу.

Этап 607: Клиент отправляет серверу сообщение, которое содержит опознавательный вызов и новый s_nonce.

Этап 608: Сервер возвращает клиенту результат обновления и новый запрос аутентификации.

Этот этап аналогичен этапу 506 и больше не описывается здесь подробно.

Этап 609: Клиент возвращает серверу сообщение, которое содержит результат аутентификации.

Этот этап аналогичен этапу 507 и больше не описывается здесь подробно.

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

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

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

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

Этап 701: Клиент принимает Инициирующее сообщение для запуска сеанса и аутентифицирует сообщение.

Этап 702: Клиент неудачно аутентифицирует Инициирующее сообщение и использует одноразовый номер по умолчанию для повторной аутентификации.

Этап 703: Клиент отправляет запрос сеанса на сервер, где запрос сеанса формируется с использованием одноразового номера по умолчанию.

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

Этап 704: Сервер аутентифицирует запрос сеанса, отправленный клиентом.

Сервер аутентифицирует запрос сеанса двумя способами:

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

Способ 2: Если сервер определяет, что сеанс использует механизм обеспечения безопасности прикладного уровня, сервер отправил клиенту Инициирующее сообщение, сформированное с использованием одноразового номера по умолчанию, и Инициирующее сообщение является Инициирующим сообщением для запуска запроса сеанса, то сервер использует одноразовый номер по умолчанию, чтобы аутентифицировать запрос сеанса. После того, как аутентификация удается, процесс переходит к этапу 705.

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

Этап оценивания того, отправил ли сервер клиенту Инициирующее сообщение, сформированное с использованием одноразового номера по умолчанию, и является ли Инициирующее сообщение Инициирующим сообщением для запуска запроса сеанса, может происходить после того, как запрос сеанса успешно аутентифицирован с использованием одноразового номера по умолчанию. После того, как оценка удается, процесс переходит к этапу 705.

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

Этап 705: Сервер возвращает клиенту сообщение с ответом.

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

Этап 706: Клиент аутентифицирует ответ, отправленный сервером.

Если сеанс использует механизм обеспечения безопасности прикладного уровня, то клиент использует одноразовый номер по умолчанию для аутентификации сервера. Способом аутентификации является: Клиент использует s_nonce для формирования аутентификационной информации для аутентификации и если аутентификация удается, то выполняет обычный процесс в соответствии с предшествующим уровнем техники. Если аутентификация терпит неудачу, то клиент использует одноразовый номер по умолчанию для формирования аутентификационной информации и снова выполняет аутентификацию. Если аутентификация удается, то клиент обновляет c_nonce, и процесс переходит к этапу 707.

Альтернативой этого этапа является: Если сеанс использует механизм обеспечения безопасности прикладного уровня, и клиент отправил серверу запрос сеанса, сформированный с использованием одноразового номера по умолчанию, то клиент использует одноразовый номер по умолчанию, чтобы аутентифицировать ответ, отправленный сервером. После того, как аутентификация удается, клиент обновляет c_nonce, и процесс переходит к этапу 707.

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

Этап 707: Клиент возвращает серверу ответ.

Клиент возвращает серверу ответ, который содержит результат аутентификации, результат обновления c_nonce и команду для обновления s_nonce.

Этап 708: Сервер возвращает клиенту результат обновления s_nonce.

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

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

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

В предшествующем уровне техники, когда s_nonce является неправильным и нуждается в обновлении, для выполнения обновления нужно обменяться командой четыре раза, как показано на этапах 203-204 на фиг.2. Поскольку одноразовый номер по умолчанию нужно использовать до того, как он обновляется, риск является высоким. Из-за сообщения, много раз передаваемого в сети подвижной связи, нагрузка на сеть становится выше.

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

Как показано на фиг.8, способ аутентификации, предусмотренный в Варианте 5 осуществления настоящего изобретения, включает в себя следующие этапы.

Этап 801: Клиенту известно, что s_nonce необходимо обновить.

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

Клиент обнаруживает несоответствие между s_nonce, сохраненным на сервере и сохраненным на клиенте, следующим образом.

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

Если аутентификация удается, это указывает, что ранее использованный сервером s_nonce является неправильным, и s_nonce, сохраненный на сервере, отличается от сохраненного на клиенте.

Этап 802: Клиент отправляет серверу запрос сеанса, который содержит информацию об обновлении.

Зная, что s_nonce необходимо обновить, клиент формирует новый s_nonce, добавляет s_nonce к запросу сеанса и отправляет запрос сеанса на сервер, запрашивая сервер начать сеанс и обновить s_nonce.

Запрос сеанса содержит SessionID, вновь сформированный s_nonce и аутентификационную информацию (Authenticate), которая включает в себя дайджест, сформированный с использованием c_nonce. В этом запросе сеанса одноразовый номер по умолчанию или ID сеанса или ID инициирующего сообщения могут использоваться в качестве одноразового номера для формирования дайджеста.

Вновь сформированный s_nonce может передаваться в SyncHdr или SyncBody запроса сеанса (SyncML).

Способ передачи описывается ниже, предполагая, что вновь сформированный s_nonce передается в SyncHdr.

Чтобы передать s_nonce, SyncHdr изменяется следующим образом:

SyncHdr (VerDTD, VerProto, SessionID, MsgID, Target, Source, RespURI?, NoResp?, Cred?, Chal?, Meta?)>

Сообщением SyncML, которое содержит s_nonce, является:

<SyncML xmlns='SYNCML:SYNCML1.2'>

<SyncHdr>

...

<Chal>

<Meta>

<NextNonce xmlns='syncml:metinf'>LG3iZQhhdmKNHg==</NextNonce>

</Meta>

</Chal>

</SyncHdr>

<SyncBody>

...

</SyncBody>

</SyncML>

Этап 803: Сервер возвращает ответ, который содержит результат аутентификации, результат обновления и запрос аутентификации.

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

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

Этап 804: Клиент возвращает серверу сообщение, которое содержит результат аутентификации.

Клиент использует обновленный s_nonce, чтобы аутентифицировать сервер. После того, как аутентификация удается, клиент возвращает серверу результат аутентификации.

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

Как показано на фиг.9, способ аутентификации, предусмотренный в Варианте 6 осуществления настоящего изобретения, включает в себя следующие этапы.

Этап 901: Сервер отправляет клиенту Инициирующее сообщение. Сообщение содержит s_nonce.

Этап 902: Сервер обнаруживает, что аутентификация терпит неудачу.

Например, если сервер в течение определенного периода не принимает от клиента никакого запроса сеанса, то сервер расценивает аутентификацию как неудачную.

Этап 903: Сервер отправляет клиенту Инициирующее сообщение. Сообщение содержит одноразовый номер Инициирующего сообщения.

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

Этап 904: Клиент обнаруживает, что s_nonce необходимо обновить.

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

Способом оценивания, использует ли Инициирующее сообщение одноразовый номер, доступный исключительно Инициирующему сообщению, является: Клиент оценивает, использует ли Инициирующее сообщение одноразовый номер Инициирующего сообщения, путем оценивания того, включает ли в себя Инициирующее сообщение поле nonce. То есть, если Инициирующее сообщение включает в себя поле nonce, то Инициирующее сообщение использует одноразовый номер Инициирующего сообщения. В качестве альтернативы клиент оценивает, использует ли Инициирующее сообщение одноразовый номер Инициирующего сообщения, путем оценивания информации поля version в Инициирующем сообщении. Это происходит потому, что поле version показывает, использует ли сообщение одноразовый номер Инициирующего сообщения.

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

Этап 905: Клиент отправляет серверу запрос сеанса, который содержит информацию об обновлении.

После приема Инициирующего сообщения и определения, что Инициирующее сообщение использует одноразовый номер Инициирующего сообщения, доступный исключительно Инициирующему сообщению, клиент оценивает, является ли допустимым одноразовый номер Инициирующего сообщения, переданный в Инициирующем сообщении. Способ оценки описывается выше. При определении, что одноразовый номер Инициирующего сообщения является допустимым, клиент ищет по дереву управления клиентом пароль, соответствующий серверу. Клиент использует найденный пароль, server-identifier и Trigger для формирования дайджеста и аутентифицирует Инициирующее сообщение. Подробный способ аутентификации описывается на этапе 301. Способ аутентификации клиента меняется в зависимости от способа формирования дайджеста.

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

Запрос сеанса содержит SessionID, обновленный s_nonce и аутентификационную информацию (Authenticate), которая включает в себя дайджест, сформированный с использованием c_nonce.

Вновь сформированный s_nonce может передаваться в SyncHdr или SyncBody запроса сеанса.

Этап 906: Сервер возвращает ответ, который содержит результат аутентификации, результат обновления и запрос аутентификации.

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

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

Этап 907: Клиент возвращает серверу сообщение, которое содержит результат аутентификации.

Клиент использует обновленный s_nonce, чтобы аутентифицировать сервер. После того, как аутентификация удается, клиент возвращает серверу результат аутентификации.

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

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

Поэтому способ аутентификации в Варианте 7 осуществления настоящего изобретения предоставляет соответствующее решение.

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

Как показано на фиг.10, характеристика состояния с новым s_nonce включает в себя Дайджест, заголовок уведомления (notification-hdr) и тело уведомления (notification-body).

Notification-hdr включает в себя версию, код состояния (status-code), ID уведомления, новый одноразовый номер (Next-nonce), зарезервированное поле (future-use), ID сеанса (SessionID), длину ID аутентификации (length-authname) и ID аутентификации (authname).

NextNonce является новым s_nonce.

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

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

S_nonce является ошибочным, если клиент определяет, что s_nonce утратил силу, или обнаруживает, что s_nonce, сохраненный на сервере, является ошибочным, например клиент определяет, что s_nonce, сохраненный на сервере, является несоответствующим или асинхронным с s_nonce, сохраненным на клиенте.

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

После обнаружения ошибки s_nonce и успешной аутентификации сервера клиент инициирует запрос сеанса. В запросе сеанса аутентификационная информация для аутентификации клиента формируется с использованием c_nonce, либо применяется основной режим аутентификации (то есть имя пользователя плюс пароль), и s_nonce дополнительно обновляется.

Два способа обновления s_nonce предоставляются соответственно в Варианте 7 осуществления и Варианте 8 осуществления способа аутентификации.

В варианте 8 осуществления сервер использует одноразовый номер по умолчанию, чтобы сформировать Инициирующее сообщение. Как показано на фиг.11, способ аутентификации включает в себя следующие этапы.

Этап 1101: Сервер отправляет клиенту Инициирующее сообщение для запуска сеанса.

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

Этап 1102: Клиент неудачно аутентифицирует Инициирующее сообщение и использует одноразовый номер по умолчанию для повторной аутентификации.

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

Если аутентификация удается, это указывает, что ранее использованный сервером s_nonce является неправильным, и s_nonce, сохраненный на сервере, отличается от сохраненного на клиенте.

Этап 1103: Клиент отправляет серверу запрос сеанса, который содержит информацию об обновлении.

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

Запрос сеанса содержит SessionID, обновленный s_nonce и аутентификационную информацию (Authenticate), которая включает в себя дайджест, сформированный с использованием c_nonce.

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

Способ добавления обновленного s_nonce к запросу сеанса в основном такой же, как в Варианте 3 осуществления и Варианте 4 осуществления, и больше здесь не повторяется.

Этап 1104: Сервер возвращает ответ, который содержит результат аутентификации, результат обновления и запрос аутентификации.

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

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

Этап 1105: Клиент возвращает серверу сообщение, которое содержит результат аутентификации.

Клиент использует обновленный s_nonce, чтобы аутентифицировать сервер. После того, как аутентификация удается, клиент возвращает серверу результат аутентификации.

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

Этап 1201: Сервер отправляет клиенту Инициирующее сообщение для запуска сеанса.

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

Этап 1202: Клиент неудачно аутентифицирует Инициирующее сообщение и использует одноразовый номер по умолчанию для повторной аутентификации.

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

Если аутентификация удается, это указывает, что ранее использованный сервером s_nonce является неправильным, и s_nonce, сохраненный на сервере, отличается от сохраненного на клиенте.

Этап 1203: Клиент успешно аутентифицирует информацию, а затем отправляет серверу запрос сеанса.

После того как удается аутентификация, клиент отправляет запрос сеанса на сервер, чтобы начать сеанс.

Запрос сеанса содержит: SessionID и аутентификационную информацию (Authenticate), которая включает в себя дайджест, сформированный с использованием c_nonce.

На этом этапе устанавливается сеансовое соединение между клиентом и сервером.

Этап 1204: Сервер возвращает ответ, который содержит результат аутентификации и запрос аутентификации.

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

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

Этап 1205: Клиент возвращает серверу команду обновления и результат аутентификации.

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

Этап 1206: Сервер возвращает клиенту результат обновления.

После приема сообщения обновления сервер обновляет сохраненный s_nonce, который указан клиентом, и возвращает клиенту результат обновления.

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

В этом случае пароль сервера может быть обновлен для повышения надежности системы.

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

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

После приема Инициирующего сообщения клиент использует сохраненный s_nonce для формирования дайджеста и аутентификации Инициирующего сообщения. Если аутентификация терпит неудачу по некоторым причинам, то клиент использует одноразовый номер по умолчанию или использует ID сеанса либо ID инициирующего сообщения в качестве одноразового номера, чтобы сформировать дайджест и повторно аутентифицировать Инициирующее сообщение. Если аутентификация удается, то клиент отправляет запрос сеанса на сервер, чтобы начать сеанс. Запрос сеанса содержит SessionID и аутентификационную информацию (Authenticate), которая включает в себя дайджест, сформированный с использованием c_nonce.

Сервер использует c_nonce, чтобы аутентифицировать запрос сеанса. Если аутентификация терпит неудачу, сервер отправляет Сообщение опознавательного вызова, чтобы обновить c_nonce и потребовать повторной аутентификации. После того, как аутентификация удается, сервер отправляет запрос аутентификации, сформированный с использованием s_nonce, и клиент использует s_nonce для аутентификации. Если аутентификация терпит неудачу, клиент отправляет Сообщение опознавательного вызова, чтобы обновить s_nonce и потребовать повторной аутентификации. После того, как аутентификация удается, клиент возвращает результат.

Дополнительно на предшествующем этапе клиент может добавить обновленный s_nonce к запросу сеанса и отправить запрос на сервер. Запрос аутентификации, отправленный сервером, использует новый s_nonce.

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

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

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

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

В варианте 10 осуществления предоставляются два способа обновления одноразового номера, которые описаны ниже.

Способ 1: Сервер обновляет одноразовый номер.

Сначала сервер выдает команду обновления одноразового номера (NextNonce). Команда NextNonce содержит новый одноразовый номер.

После приема команды NextNonce клиент использует новый одноразовый номер, переданный в команде NextNonce, чтобы обновить сохраненный одноразовый номер.

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

Как показано на фиг.13, предполагая, что ответ передается в команде NextNonce, процесс выглядит следующим образом.

Этап 1301: Сервер отправляет клиенту Инициирующее сообщение для запуска сеанса.

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

Совместно используемый c_nonce формируется сервером и доступен серверу и клиенту.

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

Этап 1302: Клиент отправляет запрос сеанса на сервер.

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

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

На этом этапе устанавливается сеансовое соединение между клиентом и сервером.

Этап 1303: Сервер возвращает ответ, который содержит результат аутентификации и запрос аутентификации, и ответ содержит команду NextNonce.

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

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

Этап 1304: После приема ответа клиент использует необновленный одноразовый номер, чтобы аутентифицировать сообщение.

Этап 1305: Аутентификация удается, и клиент использует новый одноразовый номер, переданный в команде NextNonce, чтобы обновить сохраненный совместно используемый одноразовый номер, который указан командой NextNonce.

Этап 1306: Клиент возвращает серверу сообщение, которое содержит результат аутентификации и результат обновления.

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

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

Клиент может использовать команду Alert среди команд DM, чтобы запросить у сервера обновить совместно используемый одноразовый номер. Чтобы заставить сервер понимать команду, в команду добавляется тип Alert. Тип Alert является указанием запроса к серверу для обновления одноразового номера.

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

Тип Alert может задаваться в виде org.openmobilealliance.NextNonce.

Приведенное ниже является примером сообщения с типом Alert:

<Alert>

<CmdID>2</CmdID>

<Data>1226</Data> <!--Общий Alert-->

<Item>

<Meta>

<Type xmlns="syncml:metinf">

org.openmobilealliance.NextNonce

</Type>

</Meta>

<Data/>

</Item>

</Alert>

Способ обновления одноразового номера клиентом аналогичен способу обновления одноразового номера сервером и больше здесь не повторяется.

Способ 2: Сервер и клиент совместно обновляют одноразовый номер.

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

Одноразовый номер может обновляться посредством команды NextNonce. Приведенное ниже является примером обновления:

<Chal>

<Meta>

<NextNonce xmlns='syncml:metinf'>LG3iZQhhdmKNHg==</NextNonce>

</Meta>

</Chal>

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

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

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

Вариант 10 осуществления настоящего изобретения эффективно снижает нагрузку на систему.

Как показано на фиг.14, система аутентификации, предусмотренная в Варианте 1 осуществления настоящего изобретения, включает в себя:

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

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

Сервер 1410 дополнительно включает в себя:

первый модуль 1412 формирования, приспособленный для формирования Инициирующего сообщения с использованием одноразового номера Инициирующего сообщения;

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

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

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

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

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

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

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

Модуль 1415 кодирования дополнительно включает в себя:

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

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

Клиент 1420 дополнительно включает в себя:

приемный модуль 1421, приспособленный для приема Инициирующего сообщения, сформированного с использованием одноразового номера Инициирующего сообщения;

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

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

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

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

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

Второй модуль 1424 оценки достоверности включает в себя:

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

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

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

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

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

Как показано на фиг.15, клиент, предусмотренный в Варианте 1 осуществления настоящего изобретения, включает в себя:

приемный модуль 1501, приспособленный для приема Инициирующего сообщения, отправленного сервером;

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

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

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

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

Как показано на фиг.16, клиент 1600, предусмотренный в Варианте 2 осуществления настоящего изобретения, включает в себя:

приемный модуль 1601, приспособленный для приема Инициирующего сообщения, отправленного сервером;

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

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

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

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

Как показано на фиг.17, система аутентификации, предусмотренная в Варианте 2 осуществления настоящего изобретения, включает в себя сервер 1710 и клиент 1720.

Сервер 1710 дополнительно включает в себя:

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

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

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

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

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

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

Клиент 1720 дополнительно включает в себя:

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

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

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

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

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

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

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

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

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

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

Представленное выше является способом аутентификации на основе протокола DS или протокола DM, системой, сервером и клиентом по настоящему изобретению. Хотя изобретение описывается посредством некоторых типовых вариантов осуществления, изобретение не ограничивается такими вариантами осуществления. Очевидно, что специалисты в данной области техники могут создать модификации и изменения изобретения без отклонения от объема изобретения. Изобретение должно охватывать модификации и изменения при условии, что они попадают в объем охраны, заданный нижеследующей формулой изобретения или ее эквивалентами.

Изобретение относится к технологиям связи, а именно к способу аутентификации на основе протокола синхронизации данных (DS) и протокола управления устройством (DM). Техническим результатом является предотвращение атак на сервер с повторением пакетов сообщения и повышение безопасности системы. Технический результат достигается тем, что способ для выполнения аутентификации включает в себя этапы, на которых сервер формирует инициирующее сообщение, используя случайное число инициирующего сообщения, и передает терминалу инициирующее сообщение, которое формируется с использованием случайного числа инициирующего сообщения; терминал может извлечь случайное число инициирующего сообщения, и когда терминал определяет, что случайное число инициирующего сообщения является допустимым, формирует дайджест с использованием случайного числа инициирующего сообщения и аутентифицирует инициирующее сообщение, сформированное с использованием случайного числа инициирующего сообщения; если аутентификация успешна, то терминал инициирует запрос сеанса к серверу, указанному инициирующим сообщением, причем запрос сеанса содержит идентификатор сеанса. 6 н. и 9 з.п. ф-лы, 17 ил.

1. Способ аутентификации на основе протокола Синхронизации данных (DS) или протокола Управления устройством (DM), отличающийся тем, что содержит этапы, на которых:
используют посредством сервера одноразовый номер Инициирующего сообщения, чтобы сформировать Инициирующее сообщение, при этом в качестве одноразового номера Инициирующего сообщения используют системное время сервера или идентификатор (ID) сеанса для сеанса, запускаемого Инициирующим сообщением; и
отправляют клиенту Инициирующее сообщение с помощью сервера;
извлекают посредством клиента одноразовый номер Инициирующего сообщения;
используют посредством клиента одноразовый номер Инициирующего сообщения, чтобы сформировать дайджест, и аутентифицируют Инициирующее сообщение, сформированное с использованием одноразового номера Инициирующего сообщения, после определения того, что одноразовый номер Инициирующего сообщения является допустимым; и
отправляют с помощью клиента запрос сеанса, содержащий идентификатор сеанса, на сервер, указанный Инициирующим сообщением, после того как аутентификация удается.

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

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

4. Способ по п.1 или 2, отличающийся тем, что, когда ID сеанса для сеанса, инициируемого Инициирующим сообщением, используется в качестве одноразового номера Инициирующего сообщения, при использовании сервером одноразового номера Инициирующего сообщения для формирования сервером Инициирующего сообщения:
используют посредством сервера ID сеанса для сеанса, запускаемого Инициирующим сообщением, в качестве одноразового номера Инициирующего сообщения,
аутентифицируют посредством клиента Инициирующее сообщение, используя одноразовый номер Инициирующего сообщения, при приеме Инициирующего сообщения; и
отправляют с помощью клиента запрос сеанса для запроса установления сеанса, соответствующего ID сеанса, после того как аутентификация удается.

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

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

7. Способ аутентификации на основе протокола Синхронизации данных (DS) или протокола Управления устройством (DM), отличающийся тем, что содержит этапы, на которых:
с помощью клиента принимают Инициирующее сообщение, которое отправлено сервером и сформировано с использованием одноразового номера по умолчанию, ID сеанса или ID инициирующего сообщения; и
аутентифицируют с помощью клиента Инициирующее сообщение, используя одноразовый номер сервера, после приема Инициирующего сообщения;
используют посредством клиента одноразовый номер по умолчанию, ID сеанса или ID инициирующего сообщения, чтобы аутентифицировать Инициирующее сообщение, если аутентификация Инициирующего сообщения терпит неудачу;
посредством клиента формируют запрос сеанса с использованием одноразового номера клиента после того, как аутентификация удается; и
отправляют с помощью клиента запрос сеанса на сервер, чтобы сервер аутентифицировал клиента с использованием одноразового номера клиента.

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

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

10. Способ по пп.7, 8 или 9, отличающийся тем, что содержит этап, на котором обновляют пароль сервера после обновления сохраненного одноразового номера сервера, используя новый одноразовый номер сервера.

11. Сервер, отличающийся тем, что содержит:
первый модуль формирования, приспособленный формировать Инициирующее сообщение, совместимое с протоколом Синхронизации данных (DS) или протоколом Управления устройством (DM), используя одноразовый номер Инициирующего сообщения, при этом в качестве одноразового номера Инициирующего сообщения используется системное время сервера или идентификатор (ID) сеанса для сеанса, запускаемого Инициирующим сообщением; и
модуль отправки, приспособленный отправлять клиенту Инициирующее сообщение, сформированное с использованием одноразового номера Инициирующего сообщения, чтобы клиент извлек одноразовый номер Инициирующего сообщения, аутентифицировал Инициирующее сообщение, сформированное с использованием одноразового номера Инициирующего сообщения, используя одноразовый номер Инициирующего сообщения, после определения того, что одноразовый номер Инициирующего сообщения является допустимым, и отправил запрос сеанса на сервер, указанный Инициирующим сообщением, после того как удается аутентификация Инициирующего сообщения.

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

13. Клиент, отличающийся тем, что содержит:
приемный модуль, приспособленный принимать Инициирующее сообщение, которое сформировано сервером с использованием одноразового номера Инициирующего сообщения и совместимо с протоколом Синхронизации данных (DS) или протоколом Управления устройством (DM), при этом в качестве одноразового номера Инициирующего сообщения используется системное время сервера или идентификатор (ID) сеанса для сеанса, запускаемого Инициирующим сообщением; и
первый модуль аутентификации, приспособленный извлекать одноразовый номер Инициирующего сообщения; формировать дайджест с использованием одноразового номера Инициирующего сообщения, чтобы аутентифицировать Инициирующее сообщение, сформированное с использованием одноразового номера Инициирующего сообщения, после определения того, что одноразовый номер Инициирующего сообщения является допустимым; отправлять запрос сеанса на сервер, указанный Инициирующим сообщением, после того как аутентификация удается.

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

15. Клиент, отличающийся тем, что содержит:
приемный модуль, приспособленный принимать Инициирующее сообщение, которое сформировано сервером с использованием одноразового номера по умолчанию Инициирующего сообщения и совместимо с протоколом Синхронизации данных (DS) или протоколом Управления устройством (DM); и
модуль формирования, приспособленный аутентифицировать Инициирующее сообщение с использованием одноразового номера сервера после приема Инициирующего сообщения; если аутентификация терпит неудачу, повторно аутентифицировать Инициирующее сообщение с использованием упомянутого одноразового номера по умолчанию; если аутентификация удается, формировать запрос сеанса с использованием одноразового номера клиента и отправлять запрос сеанса на сервер, чтобы сервер использовал одноразовый номер клиента для аутентификации клиента.