Способ распределения паролей

Способ генерации пароля, предназначенного для использования устройством конечного пользователя (УКП), чтобы осуществлять доступ к удаленному серверу, содержащий этапы, на которых посылают запрос доступа из УКП в удаленный сервер и посылают в узел аутентификации в собственной сети УКП детали запроса доступа и идентификационный код удаленного сервера. Генерируют в узле аутентификации или в удаленном сервере вызов HTTP Digest с использованием алгоритма, который может генерировать пароли конечных пользователей. Вызов включает в себя детали идентификационного кода удаленного сервера и идентификационного кода УКП. Генерируют и запоминают в УКП пароль на основании вызова HTTP Digest AKA, причем пароль связан с идентификационным кодом удаленного сервера и идентификационным кодом УКП. Технический результат - повышение безопасности связи. 2 н. и 15 з.п. ф-лы, 3 ил.

 

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

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

Уровень техники

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

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

Общая схема Digest-аутентификации протокола передачи гипертекста (НТТР, ППГ), как описано в документе IETF RFC 2617, может включать в себя способы, которые могут генерировать пароли конечных пользователей. Например, Digest-аутентификация НТТР, использующая соглашение аутентификации и ключа (АКА, САК), как описано в RFC 3310, является способом, предназначенным для создания паролей конечных пользователей с использованием существующей инфраструктуры аутентификации третьего поколения (3GPP), основанной на верительных данных AKA, запомненных в устойчивом к подделке устройстве, так называемых картах ISIM/USIM/SIM. Подробности вышеупомянутых общих схем можно найти в http://www.ietf.org/rfc.html. Даже если HTTP Digest AKA предоставляет гибкий способ, чтобы генерировать новые пароли без участия пользователя, оно не включает в себя стандартный способ, чтобы делегировать эти пароли третьим сторонам, таким как серверы приложений или модули-посредники. Кроме того, HTTP Digest AKA предполагает, что пароли могут использоваться только один раз.

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

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

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

В соответствии с одним аспектом настоящего изобретения предоставлен способ генерации пароля, предназначенного для использования устройством конечного пользователя (UE, УКП), чтобы осуществлять доступ к удаленному серверу, содержащий этапы, на которых:

посылают запрос доступа из УКП в удаленный сервер;

создают временный идентификационный код для УКП;

посылают в узел аутентификации в собственной сети УКП детали запроса доступа;

генерируют в узле аутентификации или в удаленном сервере вызов Digest протокола передачи гипертекста (HTTP) с использованием алгоритма, который может генерировать пароли конечных пользователей, включающий в себя детали временного идентификационного кода УКП;

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

запоминают пароль и временный идентификационный код УКП в УКП.

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

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

Временный идентификационный код УКП предпочтительно создают в удаленном сервере.

В одном варианте осуществления этап, на котором посылают детали запроса доступа в узел аутентификации, может включать в себя подэтап, на котором повторно направляют запрос доступа в узел аутентификации. Затем вызов HTTP Digest может быть сгенерирован в узле аутентификации и послан из узла аутентификации непосредственно в УКП. Пароль предпочтительно запоминают в узле аутентификации.

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

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

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

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

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

посылают запрос доступа из УКП в удаленный сервер;

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

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

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

Краткое описание чертежей

Фиг. 1 представляет схематическую иллюстрацию сети.

Фиг. 2А иллюстрирует последовательность, предназначенную для генерации пароля, и соглашение идентификационного кода между устройством конечного пользователя (УКП) и сервером приложения.

Фиг. 2В иллюстрирует альтернативную последовательность, предназначенную для генерации пароля, и соглашение идентификационного кода между устройством конечного пользователя (УКП) и сервером приложения.

Фиг. 3 иллюстрирует последовательность, участвующую в использовании нового пароля.

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

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

Фиг. 1 иллюстрирует типичную схему, в которой устройство конечного пользователя (УКП) 101, соединенное с собственной сетью 102, например универсальной мобильной телекоммуникационной системой (UMTS, УМТС), желает осуществить доступ к серверу 103 приложения, соединенному с дополнительной сетью 104. УКП 101 включает в себя устойчивое к подделке устройство, такое как идентификационный модуль служб мультимедиа IP (ISIM), в котором может быть запомнена информация. В соответствии с общей схемой соглашения аутентификации и ключа (AKA) HTTP Digest заранее устанавливают совместно используемый секрет между ISIM УКП 1 и устройством 105 аутентификации в собственной сети 102. Секрет запоминают в ISIM УКП 101.

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

Используя совместно используемый секрет и последовательный номер, УКП 101 проверяет аппаратный ключ аутентификации сети, содержащийся в запросе аутентификации, с помощью ISIM. Если проверка является успешной, сеть аутентифицирована. Затем УКП 101 создает ответ аутентификации с использованием совместно используемого секрета и случайного вызова и подает его в сервер 103 приложения. Сервер 103 приложения сравнивает ответ аутентификации, принятый из УКП 101, с ожидаемым ответом, принятым из устройства 103 аутентификации. Если они совпадают, пользователь успешно аутентифицирован, и ключи сеанса в векторе аутентификации могут быть использованы для защиты дополнительных связей между УКП 101 и сервером 103 приложения. Однако, когда в следующий раз УКП 101 пожелает осуществить доступ к серверу 103 приложения, можно следовать той же самой процедуре, чтобы аутентифицировать сеть и получить ключи сеанса, отсутствует механизм, предназначенный для запоминания пароля для будущего использования с помощью УКП 101.

Фиг. 2 изображает один вариант осуществления системы, предназначенной для аутентификации УКП 101 в сервер 103 приложения (AS, СП). На первом этапе УКП 101 аутентифицируют с использованием HTTP Digest AKA и созданный пароль связывают с идентификационными кодами сервера 103 приложения и УКП 101. Для того чтобы понять процессы, изображенные на фиг. 2А, необходимо определить две концепции, используемые в общей схеме аутентификации HTTP Digest.

'Область действия' - это строка, которая указывает УКП 101, какое имя пользователя и пароль использовать. Эта строка содержит, по меньшей мере, имя центра 103 аутентификации и могла бы дополнительно указывать на группу пользователей, которые могли бы иметь доступ. Примером могло бы быть "[e-mail]" ("зарегистрированные пользователи @ собственная сеть.com"). В контексте 3GPP/AKA область действия собственной сети обычно запоминают в карте SIM/USIM/ISIM УКП 101.

'Имя пользователя' - это имя пользователя в определенной области действия. Эта строка используется сервером 103 приложения, чтобы находить правильный пароль для пользователя. В контексте 3GPP/AKA имя пользователя, используемое с собственной сетью, обычно запоминают в карте SIM/USIM/ISIM УКП 101. В большинстве случаев имя пользователя является тем же самым, что и так называемый личный идентификационный код (IMPI). Имя пользователя 3GPP идентифицирует подписку, и по этой причине пароли являются специфичными для устройства конечного пользователя, а не реального конечного пользователя. В обычной общей схеме аутентификации HTTP имя пользователя и пароль печатаются конечным пользователем, но в контексте 3GPP/AKA эти поля автоматически заполняются с помощью УКП 101.

Как изображено на фиг. 2А, на первом этапе УКП 101 и сервер 103 аутентификации не имеют совместно используемого секрета. УКП 101 сначала аутентифицируют с использованием HTTP Digest AKA и созданный пароль связывают с идентификационными кодами УКП 101 и сервера 103 приложения. Процедура имеет следующие этапы.

1а) УКП 1 посылает запрос HTTP (обычно HTTP GET) в сервер 103 приложения.

2а) Так как сервер 103 приложения и УКП 101 не имеют совместно используемого секрета, сервер 103 приложения повторно направляет запрос в устройство 105 аутентификации. Перед повторным направлением запроса сервер 103 приложения может определить новое временное имя пользователя для УКП 101. Сервер 103 приложения включает это имя пользователя и информацию своего собственного идентификационного кода в запрос. Информацию идентификационного кода обычно кодируют в параметр URI, УАР (универсальный адрес ресурса) в формате некоторого стандарта, например, "username@relm" ("имя пользователя@область действия").

3а) Устройство 105 аутентификации проверяет, чтобы понять, санкционирован ли сервер 103 приложения, чтобы выполнить повторное направление HTTP и запрос нового пароля HTTP Digest AKA для УКП 101. Если это имеет место, тогда устройство 105 аутентификации берет информацию идентификационного кода из запроса и кодирует эту информацию в вызове HTTP Digest AKA, который посылают в УКП 101. В одном варианте осуществления устройство 105 аутентификации вставляет информацию идентификационного кода в так называемые "серверные данные" данного случая HTTP Digest AKA, как описано в RFC 3310. С помощью включения идентификационного кода в вызов устройство 105 аутентификации может быть уверено, что идентификационный код сервера 103 аутентификации или временный идентификационный код конечного пользователя не может быть изменен любой стороной (такой как взломщик) между УКП 101 и устройством 103 аутентификации, поскольку вызов возвращают обратно в устройство 105 аутентификации в следующем сообщении.

4а) УКП 101 аутентифицирует сеть (как определено в стандартном протоколе AKA) и генерирует новый пароль, основанный на вызове HTTP Digest AKA. УКП локально запоминает идентификационный код сервера 103 приложения и вновь сгенерированный пароль, используемые позже для взаимной аутентификации с сервером 103 приложения. Если вызов включал также новое временное 'имя пользователя', сгенерированное с помощью сервера 103 приложения, это имя пользователя также запоминают с паролем и идентификационным кодом сервера 104 приложения. Идентификационные коды как сервера приложения, так и УКП кодируют в запросе HTTP Digest AKA, например, с использованием формата "username@realm" ("имя пользователя@область действия"). УКП 101 посылает ответ аутентификации в устройство 103 аутентификации.

Новое 'имя пользователя' отмечают как временное имя пользователя с помощью УКП 101. Это имя пользователя и связанный пароль HTTP Digest AKA удаляют, когда новое 'имя пользователя' и пароль сгенерированы для той же самой области действия. Если вызов не включает в себя новое временное имя пользователя, тогда существующее имя пользователя может быть повторно использовано.

5а) Устройство 105 аутентификации аутентифицирует УКП 101 и, если аутентификация успешна, запоминает новый пароль и идентификационные коды УКП 101 и сервера 103 приложения, используемые позже. Запрос повторно направляют обратно в сервер 103 приложения.

Если является подходящим, сервер 103 приложения может доверять начальной аутентификации, выполненной с помощью устройства 105 аутентификации. Если устройство 105 аутентификации не воспринимают как защищенное, сервер 103 аутентификации может также выполнить повторный вызов УКП 101, в текущий момент использующее вновь сгенерированный пароль. В это время HTTP Digest AKA не используется для аутентификации. Вместо этого используется HTTP Digest с некоторым другим алгоритмом, например может использоваться MD5, как описано в REC 21617.

Фиг. 2В изображает альтернативный вариант осуществления системы, предназначенной для аутентификации УКП 101 в сервер 103 приложения (СП). Первый этап выполняют с использованием другой процедуры, имеющей следующие этапы.

1b) УКП 1 посылает запрос HTTP (обычно HTTP GET) в сервер 103 приложения.

2b) Так как сервер 103 приложения и УКП 101 не имеют совместно используемого секрета, сервер 103 приложения запрашивает вызов аутентификации HTTP Digest AKA непосредственно из устройства аутентификации. Как в ранее описанном варианте осуществления запрос может включать в себя идентификационный код сервера 103 приложения и новый временный идентификационный код УКП 101.

3b) Устройство 105 аутентификации проверяет, чтобы понять, санкционирован ли сервер 103 приложения, чтобы запросить новый пароль HTTP Digest AKA для УКП 101. Если это имеет место, тогда устройство аутентификации берет информацию идентификационного кода сервера приложения и временного идентификационного кода конечного пользователя (если присутствует) из запроса и кодирует эту информацию в вызове HTTP Digest AKA, как в ранее описанном варианте осуществления. В качестве альтернативного варианта сервер 103 приложения также может включать эту информацию в вызов на этапе 4b, описанном ниже. Информацию идентификационного кода кодируют в формате некоторого стандарта, например, username@relm (имя пользователя@область действия) или username@remote_realm (имя пользователя@удаленное устройство_область действия). Информацию, требуемую сервером 103 приложения, чтобы создать вызов HTTP Digest AKA, посылают обратно в сервер 103 приложения. Если эти параметры включают в себя пароль HTTP Digest AKA, тогда этапы 6b) и 7b) могут не требоваться.

4b) УКП 101 вызывают с помощью вызова аутентификации HTTP Digest AKA. Сервер 103 приложения может добавить идентификационные коды сервера приложения и конечного пользователя в вызов аутентификации перед посылкой вызова в УКП 101. Однако в этом случае сервер 103 приложения должен быть конечным пунктом для аутентификации и должен обладать паролем HTTP Digest AKA.

5b) УКП 101 аутентифицирует сеть (как определено в стандартном протоколе AKA) и генерирует новый пароль, основанный на вызове HTTP Digest AKA. УКП локально запоминает идентификационный код сервера 103 приложения (например, "область действия"), вновь сгенерированный пароль и новое временное 'имя пользователя' для себя (если присутствует), используемые позже сервером 103 приложения для взаимной аутентификации с сервером 103 приложения (если присутствует). УКП 101 посылает ответ аутентификации в сервер 103 приложения. Как в ранее описанном варианте осуществления УКП 101 отмечает возможное новое 'имя пользователя' как временное имя пользователя.

6b) Если сервер 103 приложения не принял пароль конечного пользователя на этапе 3b выше, он теперь запрашивает устройство 105 аутентификации выполнить аутентификацию.

7b) Если сервер 103 приложения не принял пароль конечного пользователя на этапе 3b выше и он запросил аутентификацию на этапе 6b), устройство 105 аутентификации аутентифицирует УКП 101 и возвращает соответствующий результат в сервер 103 приложения. Устройство 105 аутентификации также может послать пароль конечного пользователя в сервер 103 приложения на этом или некотором более позднем этапе.

8b) Если аутентификация УКП 101 была успешной, службу подают в УКП 101.

Следование процедурам, описанным выше со ссылкой на фиг. 2A либо фиг. 2B, имеет результатом то, что сервер 103 приложения и УКП 101 имеют совместно используемый секрет. В следующий раз, когда сервер 103 приложения должен будет аутентифицировать УКП 101 (что может быть непосредственно после предыдущих процедур или после некоторого более длительного периода времени, например, в следующий раз, когда УКП 101 будет контактировать с сервером 103 приложения), процедура является такой, как изображена на фиг. 3.

1с) УКП 101 посылает запрос HTTP (обычно HTTP GET) в сервер 103 приложения.

2с) Так как сервер 103 приложения и УКП 101 теперь имеют совместно используемый секрет, сервер 103 приложения вызывает УКП 101 с помощью вызова HTTP Digest. Вызов включает в себя идентификационный код сервера 103 приложения в параметре 'область действия'.

3с) УКП 101 посылает ответ аутентификации (обычно запрос HTTP GET) обратно в сервер 103 приложения с использованием нового временного 'имени пользователя' и пароля для сервера 103 приложения, созданных во время предыдущего этапа (описанного выше со ссылкой на фиг. 2В или фиг. 2С). Если новое временное имя пользователя не было создано, тогда используется обычное специфичное имя пользователя AKA. УКП 101 использует параметр "область действия", чтобы идентифицировать правильный пароль.

4с) Если сервер 103 приложения обладает паролем конечного пользователя, этот этап и следующий этап (5с) не требуются. Если сервер 103 приложения не обладает паролем конечного пользователя, тогда сервер 103 приложения запрашивает из устройства 105 аутентификации (или некоторого другого объекта сети (не изображен), где устройство 105 аутентификации запомнило специфичный пароль УКП) аутентификацию.

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

Если аутентификация была успешной, СП подает службу в УКП.

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

1. Способ генерации пароля, предназначенного для использования устройством конечного пользователя (УКП), чтобы осуществлять доступ к серверу приложения, содержащий этапы, на которых

посылают запрос доступа из УКП в сервер приложения;

создают временный идентификационный код для УКП;

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

проверяют в устройстве аутентификации, санкционирован ли сервер приложения для выполнения операции повторного направления с использованием HTTP и запроса нового пароля HTTP Digest AKA для УКП;

генерируют в устройстве аутентификации или в сервере приложения вызов Digest протокола передачи гипертекста (HTTP), включающий в себя детали временного идентификационного кода УКП;

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

2. Способ по п.1, в котором этап генерации пароля основан на соглашении аутентификации и ключа (AKA) HTTP Digest.

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

4. Способ по п.1, в котором временный идентификационный код УКП создают в сервере приложения.

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

6. Способ по п.5, в котором вызов HTTP Digest генерируют в устройстве аутентификации и посылают из устройства аутентификации непосредственно в УКП.

7. Способ по п.5, в котором пароль запоминают в устройстве аутентификации.

8. Способ по п.5, дополнительно содержащий этапы, на которых УКП аутентифицируют в устройстве аутентификации и повторно направляют запрос доступа из устройства аутентификации обратно в сервер приложения после того, как пароль сгенерирован.

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

10. Способ по п.9, в котором вызов HTTP Digest генерируют в устройстве аутентификации и посылают из устройства аутентификации в сервер приложения.

11. Способ по п.9, в котором вызов HTTP Digest генерируют в сервере приложения.

12. Способ по п.10, дополнительно содержащий этап, на котором посылают вызов HTTP Digest АКА из сервера приложения в УКП.

13. Способ по п.11, дополнительно содержащий этапы, на которых включают пароль вызова HTTP Digest АКА в информацию, посылаемую из устройства аутентификации в сервер приложения, и аутентифицируют УКП в сервере приложения.

14. Способ по п.9, дополнительно содержащий этапы, на которых УКП аутентифицируют в устройстве аутентификации и возвращают результат аутентификации в сервер приложения.

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

генерируют и запоминают пароль в УКП, используя способ по любому одному из предшествующих пунктов;

посылают запрос доступа из УКП в сервер приложения;

генерируют в сервере приложения вызов Digest протокола передачи гипертекста (HTTP), включающий в себя детали идентификационного кода сервера приложения, и посылают вызов в УКП; и посылают из УКП ответ аутентификации, включающий в себя временный идентификационный код УКП, в сервер приложения.

16. Способ по п.15, дополнительно содержащий этапы, на которых посылают запрос аутентификации из сервера приложения в устройство аутентификации, посылают пароль из устройства аутентификации в сервер приложения и аутентифицируют УКП в сервере приложения.

17. Способ по п.15, дополнительно содержащий этапы, на которых посылают запрос аутентификации из сервера приложения в устройство аутентификации, аутентифицируют УКП в устройстве аутентификации и посылают подтверждение аутентификации из устройства аутентификации в сервер приложения.