2446593 - Способ аутентификации, система, сервер и клиент

Способ аутентификации, система, сервер и клиент

Иллюстрации

Показать все

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

Реферат

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

Настоящее изобретение относится к технологиям связи, в частности к способу аутентификации на основе протокола Синхронизации данных (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 в варианте осуществления настоящего изобретения включает в себя:

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

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

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

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

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

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

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

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

первый модуль формирования, приспособленный для использования одноразового номера Инициирующего сообщения для формирования Инициирующего сообщения, совместимого с протоколом 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>

</Alert>

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

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

<X>/AppAuth/<X>/SNAAuthCount

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

<Item>

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

</Target>

</Item>

</Replace>

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

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

Способ аутентификации, система, сервер и клиент

Патент 2446593