Защита конфиденциальности в системах связи
Иллюстрации
Показать всеИзобретение относится к системам связи, а именно к защите конфиденциальности пользователя в системе связи. Техническим результатом является повышение конфиденциальности пользователя в системе связи. Технический результат достигается тем, что пользователь формирует идентификатор вторичного ключа на основе вторичного ключа и первой переменной сеанса, связанной с первым сеансом, и отправляет идентификатор вторичного ключа приложению, формирует ключ трафика, связанный с упомянутым идентификатором вторичного ключа и осуществляет безопасную связь с упомянутым приложением с помощью упомянутого ключа трафика во время первого сеанса, при этом осуществляется согласование с упомянутым приложением второй переменной сеанса для связи во время последующего второго сеанса. 12 н. и 21 з.п. ф-лы, 3 ил.
Реферат
Заявление о приоритете 35 U.S.C. §119
По настоящей заявке на выдачу патента испрашивается приоритет по предварительной заявке № 60/758,971, поданной 13 января 2006 года, и предварительной заявке № 60/762,771, поданной 27 января 2006 года, обе переданы правопреемнику настоящей заявки, и полные раскрытия которых, таким образом, включены по ссылке в данный документ.
Область техники, к которой относится изобретение
Настоящее изобретение, в целом, относится к связи, а более конкретно к защите конфиденциальности пользователя в системах связи.
Уровень техники
Так как современные устройства получили возможность связываться с произвольными серверами приложений, существует необходимость аутентифицировать и защищать такие связи. В системах с асимметричным или открытым ключом устройство (или "пользователь") может представить открытый ключ серверу приложений (или "приложению"), тогда как отдельный закрытый ключ сохраняется конфиденциальным. В системах с общим или симметричным ключом пользователь может проводить связи с приложением с помощью удостоверения пользователя, которое может быть "анонимным" в том, что удостоверение пользователя может не открывать, кем фактически является пользователь. При приеме этого удостоверения пользователя приложение может затем получить ключ, связанный с этим удостоверением пользователя, чтобы войти в зашифрованную связь с пользователем. Ключ может быть заранее известен приложению, или он может быть получен от сервера ключей, например, третьей стороны, которой доверяют и пользователь, и приложение.
Существуют конкретные способы, в которых конфиденциальность пользователя может быть скомпрометирована в этих системах, даже когда используется "анонимное" удостоверение пользователя. Например, если пользователь обменивается одним и тем же удостоверением пользователя с приложением во множестве сеансов, приложение может вывести частную информацию о пользователе, связывая сеансы пользователя друг с другом. Это называется "атакой по возможности связывания". Например, в беспроводной сети использование одного удостоверения, чтобы обратиться к нескольким базовым станциям, может привести к отслеживанию пользователя в сети. Альтернативно, если пользователь обращается к нескольким разным приложениям с помощью одного и того же удостоверения пользователя, тогда третья сторона может установить, к каким приложениям пользователь обратился, и когда пользователь обратился к ним, пассивно подслушивая передачу удостоверения пользователя между приложением и сервером ключей. Это потенциально открывает частную информацию о предпочтениях пользователя. Та же информация может быть получена третьей стороной, непосредственно запрашивающей приложения, к которым осуществлен доступ.
Раскрытие изобретения
Один аспект настоящего изобретения представляет способ защиты конфиденциальности пользователя, содержащий формирование вторичного удостоверения, связанного с пользователем на основе ключа и, по меньшей мере, одного параметра, содержащего переменную сеанса; и отправку упомянутой вторичного удостоверения приложению.
Другой аспект настоящего изобретения предоставляет способ защиты конфиденциальности пользователя во время связи в системе, имеющей сервер ключей, упомянутый способ содержит прием от пользователя вторичного удостоверения, сформированного из ключа и, по меньшей мере, одного параметра, содержащего переменную сеанса; передачу упомянутого вторичного удостоверения упомянутому серверу ключей; и прием от упомянутого сервера ключей информации, связанной с упомянутым пользователем.
Еще один аспект настоящего изобретения предоставляет способ защиты конфиденциальности пользователя, содержащий прием от пользователя вторичного удостоверения ключа, сформированного из ключа и, по меньшей мере, одного параметра, содержащего переменную сеанса; и идентификацию упомянутого ключа из упомянутого вторичного удостоверения ключа.
Еще один аспект настоящего изобретения предоставляет способ защиты конфиденциальности пользователя во время связи в системе, имеющей сервер ключей, упомянутый способ содержит прием от запрашивающего приложения вторичного удостоверения, сформированного из ключа и, по меньшей мере, одного параметра, содержащего переменную сеанса; и идентификацию упомянутого пользователя из упомянутого вторичного удостоверения.
Еще один аспект настоящего изобретения предоставляет устройство для защиты конфиденциальности пользователя, содержащее генератор вторичного удостоверения для формирования вторичного удостоверения, связанного с пользователем, на основе ключа и, по меньшей мере, одного параметра, содержащего переменную сеанса; передатчик для отправки упомянутого вторичного удостоверения приложению.
Еще один аспект настоящего изобретения предоставляет устройство для защиты конфиденциальности пользователя во время связи в системе, имеющей сервер ключей, упомянутое устройство содержит приемник для приема от пользователя вторичного удостоверения, сформированного из ключа и, по меньшей мере, одного параметра, содержащего переменную сеанса; и передатчик для передачи упомянутого вторичного удостоверения пользователя упомянутому серверу ключей.
Еще один аспект настоящего изобретения предоставляет устройство для защиты конфиденциальности пользователя, содержащее приемник для приема от пользователя вторичного удостоверения ключа, сформированного из ключа и, по меньшей мере, одного параметра, содержащего переменную сеанса; процессор для идентификации упомянутого ключа из упомянутого вторичного удостоверения ключа.
Еще один аспект настоящего изобретения предоставляет устройство для защиты конфиденциальности пользователя во время связи в системе, имеющей сервер ключей, упомянутое устройство содержит приемник для приема от запрашивающего приложения вторичного удостоверения, сформированного из ключа и, по меньшей мере, одного параметра, содержащего переменную сеанса; и процессор для идентификации упомянутого пользователя из упомянутого вторичного удостоверения.
Еще один аспект настоящего изобретения предоставляет устройство для защиты конфиденциальности пользователя во время связи с приложением, упомянутое устройство содержит средство для формирования вторичного удостоверения; средство для отправки упомянутого вторичного удостоверения приложению.
Еще один аспект настоящего изобретения предоставляет устройство для защиты конфиденциальности пользователя во время связи в системе, имеющей сервер ключей, упомянутое устройство содержит приемник для приема от запрашивающего приложения вторичного удостоверения, сформированного из ключа и, по меньшей мере, одного параметра, содержащего переменную сеанса; средство для идентификации упомянутого пользователя из упомянутого вторичного удостоверения; и передатчик для передачи информации, связанной с упомянутым пользователем, упомянутому запрашивающему приложению.
Краткое описание чертежей
Фиг. 1 иллюстрирует вариант осуществления настоящего изобретения, в котором сервер ключей используется для того, чтобы способствовать зашифрованной связи между пользователем и приложением.
Фиг. 2 иллюстрирует вариант осуществления процесса или способа, в котором пользователь может установить безопасную связь с приложением согласно варианту осуществления, показанному на Фиг. 1.
Фиг. 3 иллюстрирует вариант осуществления процесса или способа, в котором пользователь может безопасно связаться с приложением, без использования сервера ключей.
Осуществление изобретения
Чтобы защитить конфиденциальность пользователя, существует необходимость в предоставлении безопасной связи между пользователем и приложением, без открытия фактического удостоверения пользователя приложению или третьей стороне, подслушивающей связь, или иного предоставления возможности приложению определять, что другие сеансы начинаются от того же пользователя. Изобретение, раскрытое в данном документе, устраняет этот недостаток.
Ссылка теперь направлена на Фиг. 1, которая иллюстрирует вариант осуществления системы 100 связи, в которой сервер ключей используется для того, чтобы способствовать зашифрованной связи между пользователем и приложением.
Система 100 связи может быть любой голосовой системой, системой передачи данных или мультимедийной системой, например, работающей по стандарту и/или протоколу связи, такому как WCDMA (широкополосный множественный доступ с кодовым разделением каналов), cdma2000 или IP-стандарт (протокол Интернета) или любой другой подходящий стандарт или протокол. Вариант осуществления может использоваться, например, как расширение к универсальной архитектуре самозагрузки, как определено в различных стандартах связи. (См., например, "Generic Authentication Architecture (GAA): Generic bootstrapping architecture," 3GPP TS 33.220 и "Generic Bootstrapping Architecture (GBA) Framework," 3GPP2 S.S0109-0 Версия 1).
Как иллюстрировано на Фиг. 1, пользователь 114 (также именуемый как пользовательское оборудование) может обратиться к приложению 116 в системе 100. Приложение 116 может быть выделенным сервером в сети, обслуживающим определенное приложение, например, VoIP (голос по протоколу Интернета), или сам элемент сети. Приложение 116 может также быть программным приложением, сохраненным на серверах или других устройствах в сети. В варианте осуществления (не показан) приложение 116 может находиться в том же физическом устройстве, что и сервер 126 ключей. Каждое приложение может иметь свою собственную выделенную схему передатчика/приемника (не показана) для связи с пользователем 114 и/или сервером 126 ключей, или несколько приложений могут совместно использовать общую схему передатчика/приемника. Может быть отмечено, что приложение может включать в себя несколько физических объектов, например приложение может быть полностью мобильной сетью, содержащей множество базовых станций.
В одном варианте осуществления пользователь 114 может предварительно сохранить ключ 102 в своей памяти. И ключ 102, и тот факт, что он сохранен у пользователя 114, известны серверу 126 ключей. Ключ 102 может быть уникальным для пользователя 114 или группы пользователей, которая включает в себя пользователя 114. Ключ 102 может использоваться постоянно или только в течение конкретного периода времени. В варианте осуществления ключ 102 известен только авторизованным сторонам, таким как сервер 126 ключей и пользователь 114.
В одном варианте осуществления как пользователь 114, так и сервер 126 ключей могут формировать temp_ID 108 (также именуемый вторичным удостоверением) с помощью следующей общей формулы:
temp_id=F(ключ, m Уравнение (1)
В Уравнении (1) F - это предварительно определенная алгоритмическая функция, такая как криптографическая хэш-функция. Альтернативно, F может быть функцией, которая последовательно связывает один или более параметров с выводом одной или более хэш-функций. F также может быть функцией, которая выполняет хэширование по комбинации ряда параметров с выводом одной или более других хэш-функций. В одном варианте осуществления предварительно определенная алгоритмическая функция может быть защищенным алгоритмом хэширования SHA-1 (См. публикацию федерального стандарта обработки информации 180-1 (1995).)
Также в Уравнении (1) m означает набор параметров, который может включать в себя, например, удостоверение пользователя, одну или более зависимых от сеанса переменных и/или другие параметры. Сеанс может означать установление связи между пользователем и приложением, в которой используется тот же temp_ID. В варианте осуществления m, как правило, включает в себя, по меньшей мере, одну переменную сеанса, которая может изменяться каждый раз, когда выполняется обмен temp_ID с приложением. Такая переменная может быть цифровым увеличивающимся счетчиком использований, временной отметкой или выводом генератора псевдослучайных чисел. Будет понятно, что более крупные переменные сеанса могут использоваться для большей безопасности ценой большей сложности осуществления. В варианте осуществления переменная сеанса может быть 16-битным значением счетчика.
Обращаясь опять к Фиг. 1, как F, так и m известны пользователю 114 и серверу 126 ключей. В одном варианте осуществления сервер 126 ключей может предварительно вычислить и сохранить значения temp_ID на основе данного ключа 102 и всех возможных значений параметра m, так что данный temp_ID, ключ 102, используемый, чтобы сформировать его, может быть быстро идентифицирован.
Фиг. 2 иллюстрирует вариант осуществления процесса или способа 200, в котором пользователь 114 может установить безопасную связь с приложением 116 согласно варианту осуществления, показанному на Фиг. 1. Сначала, на этапе 201 пользователь 114 вычисляет temp_ID 108 из ключа и набора m параметров и отправляет temp_ID 108 приложению 116.
На этапе 202, после того как принят temp_ID 108, отправленный пользователем 114, приложение 116 отправляет temp_ID 108 серверу 126 ключей.
Как описано ранее, в одном варианте осуществления сервер 126 ключей имеет предварительно сохраненный набор temp_ID и ключей в своей памяти. На этапе 203 сервер 126 ключей использует temp_ID 108, принятый от приложения 116, чтобы идентифицировать ключ 102. Как упомянуто ранее, каждый ключ может соответствовать уникальному пользователю. В этом примере ключ 102 соответствует пользователю 114. Сервер 126 ключей может, поэтому, сопоставить temp_ID 108 с пользователем 114, как показано на этапе 203.
На этапе 203 сервер 126 ключей может дополнительно сформировать sub_key 238 (также называемый ключом трафика в данном документе) на основе ключа 102. Это формирование подключа может использовать другую алгоритмическую функцию и содержать параметры, известные только пользователю 114 и серверу 126 ключей. В одном варианте осуществления значение temp_ID 108 само может использоваться в формировании связанных подключей. В альтернативном варианте осуществления любое число подключей 238 может быть сформировано посредством взятия хэш-функции (например, SHA-1) ключа 102 и соответствующего порядкового номера.
На этапе 204 сервер 126 ключей отправляет sub_key 238 приложению 116. Сервер 126 ключей может также отправить другую информацию о пользователе 114 приложению 116.
Пользователь 114 может независимо сформировать sub_key 238 (или "ключ трафика") из параметров, уже известных ему. Таким образом, с помощью sub_key 238, известного и приложению 116, и пользователю 114, обе стороны могут использовать sub_key 238, чтобы зашифровать и расшифровать данные 240, отправленные между ними, как изображено на этапе 205.
Обращаясь обратно к Фиг. 1, если пользователь 114 впоследствии обращается к другому приложению 122, temp_ID, отличный от temp_ID 108, может быть вычислен в соответствии с уравнением (1), как описано выше. Если функция F выбрана, так что связь между temp_ID 108 и другими temp_ID, используемыми во время других сеансов тем же пользователем, трудно различима, неавторизованной стороне будет трудно связать перехваченный temp_ID с каким-либо отдельным пользователем, таким образом, сохраняя конфиденциальность удостоверения пользователя.
В одном варианте осуществления набор m параметров, используемый, чтобы сформировать temp_ID в уравнении (1), может включать в себя удостоверение приложения (app_ID), соответствующего приложению, к которому осуществлен доступ. В этом способе сервер 126 ключей может указать из temp_ID 108, был ли в действительности пользователем 114 осуществлен доступ к приложению 116, запрашивающему пользовательскую информацию у сервера 126 ключей. Для безопасности сервер 126 ключей может выбрать отправку информации о пользователе 114, включающую в себя удостоверение пользователя и конкретный для пользователя ключ, только приложению 116, чей app_ID соответствует app_ID, использованному, чтобы сформировать temp_ID 108. Это предотвращает получение информации о пользователе 114 от сервера 126 ключей другим приложением, таким как приложение 118, к которому не обращался пользователь 114.
В варианте осуществления пользователь 114 может даже быть приглашен, чтобы сформировать temp_ID, когда пользователь 114 еще не знает app_ID приложения, к которому он желает получить доступ. В этом случае пользователь может, тем не менее, сформировать temp_ID, используя фиксированный "универсальный" или "по умолчанию" app_ID вместо конкретного для приложения app_ID. В этом варианте осуществления сервер ключей может быть выполнен с возможностью узнавать temp_ID, содержащий в себе такой "универсальный" или "по умолчанию" app_ID, и предоставляет конкретные для пользователя данные приложению, даже если универсальный app_ID не соответствует app_ID запрашивающего приложения. В более позднее время, после того как пользователь выяснил app_ID приложения, пользователь может сформировать новый temp_ID на основе правильного app_ID.
В другом варианте осуществления изобретения, если новый набор m' параметров согласован пользователем и приложением во время сеанса, тогда, запрашивая сервер ключей, приложение может определить новый temp_ID, который должен использоваться во время последующего сеанса. Чтобы выполнить это, приложение может предоставить, например, новый набор m' параметров вместе с temp_ID, первоначально принятым от пользователя, серверу ключей. Это предохраняет пользователя от необходимости передавать новый temp_ID приложению каждый раз, когда требуется использование нового temp_ID.
Фиг. 3 иллюстрирует вариант осуществления процесса или способа 300, в котором пользователь 114 может безопасно связаться с приложением 116 без использования сервера ключей. В этом варианте осуществления предполагается, что пользователь 114 и приложение 116 уже совместно используют ключ K через некоторую схему распространения ключа до начала связи, изображенной на Фиг. 3. В варианте осуществления ключ K является переменной, известной только авторизованным сторонам, таким как пользователь и приложение.
На этапе 301 пользователь 114 может формировать Derived_Key_ID 310 как следующее:
Derived_Key_ID=F(K, переменная сеанса, другие параметры) Уравнение (2),
где F снова является предварительно определенной алгоритмической функцией, переменная сеанса является зависимой от сеанса переменной, такой как значение счетчика, а другие параметры могут включать в себя любой параметр, явно не перечисленный в данном документе, который известен и пользователю 114, и приложению 116. Как ранее отмечено, переменная сеанса может изменяться каждый раз, когда temp_ID обменивается с приложением, и может быть цифровым увеличивающимся счетчиком использований, временной меткой или выводом генератора псевдослучайных чисел. Будет понятно, что более крупные переменные сеанса могут использоваться для большей безопасности ценой большей сложности осуществления. В варианте осуществления переменная сеанса может быть 16-битным значением счетчика.
На этапе 302 пользователь 114 отправляет Derived_Key_ID 310 приложению 116. На этапе 303 приложение 116, которое предварительно вычислило набор Derived_Key_ID по всем возможным значениям ключа K, переменную сеанса и другие параметры и сохранило этот набор в памяти, может идентифицировать ключ K, переменную сеанса, использованную, чтобы сформировать принятый Derivded_Key_ID 310, и связанного пользователя 114. Когда обе стороны знают значения K, переменную 331 сеанса и другие параметры, обе стороны могут вычислить общий ключ Derived_K 332 как следующее:
Derived_K=G(K, переменная сеанса, другие параметры) Уравнение (3),
где G является другой предварительно определенной алгоритмической функцией, а переменная 331 сеанса соответствует переменной сеанса, используемой для того, чтобы сформировать Derived_key_ID 310 в уравнении (2). Может быть отмечено, что функция G может быть выбрана, чтобы быть такой же что и использованная, чтобы сформировать sub_key 238, описанный ранее со ссылкой на Фиг. 2. Безопасная связь может теперь быть проведена с помощью Derived_K 332, чтобы отправить и принять зашифрованные данные 340, как показано на этапе 304.
В дополнительном варианте осуществления изобретения, если новый набор m' параметров согласован пользователем и приложением во время сеанса, тогда приложение может определить с помощью уравнения (3) новый temp_ID, который должен использоваться во время последующего сеанса. Это обеспечит защиту против атак по возможности связи третьей стороной. Например, пользователь может изменять свои temp_ID во время сеансов с разными базовыми станциями в мобильной сети, чтобы избежать отслеживания подслушивающей третьей стороной.
Может быть отмечено, что вышеупомянутые варианты осуществления были описаны в контексте систем с общим ключом или симметричных криптографических систем, системы с открытым ключом или асимметричные криптографические системы также восприимчивы к атакам по возможности связи, где пользователь повторно использует один и тот же открытый ключ. Аспекты настоящего изобретения могут также применяться, чтобы изменить закрытый ключ и, следовательно, открытый ключ согласно зависимой от сеанса переменной и/или удостоверения приложения. Может быть отмечено, однако, что в системах с открытым ключом служебные данные регистрации и процессы выдачи сертификата, требуемые каждый раз, когда пара открытый/закрытый ключ изменяется, могут привести к тому, что пара открытый/закрытый ключ предпочтительно используется в течение продолжительного периода времени.
Согласно варианту осуществления память в каждом из сервера 126 ключей и пользователя 114 может быть либо энергозависимого, либо энергонезависимого типа, такого как накопитель на жестком магнитном диске или схема RAM (оперативное запоминающее устройство). Как альтернатива, память может быть сделана из других типов схем, таких как EEPROM (электрически стираемое программируемое постоянное запоминающее устройство), EPROM (электрически программируемое постоянное запоминающее устройство), ROM (постоянное запоминающее устройство), ASIC (специализированная интегральная микросхема), магнитный диск, оптический диск и другие, хорошо известные в области техники.
Должно быть отмечено, что изобретение может быть осуществлено как процесс или способ и быть закодировано как машиночитаемые инструкции, переносимые на любом машиночитаемом носителе, известном в данной области техники. Здесь, термин "машиночитаемый носитель" ссылается на любой носитель, который участвует в предоставлении инструкций какому-либо процессору, такому как процессоры в сервере 126 ключей и пользователе 114, показанных на Фиг. 1. Такой носитель может быть накопительного типа и может принимать форму энергозависимого или энергонезависимого носителя хранения, как также описано ранее, например, в описании памяти и сервера 126 ключей и пользователя 114. Такой носитель может также быть передающего типа и может включать в себя коаксиальный кабель, медный провод, оптический кабель и радиоинтерфейс, передающий звуковые или электромагнитные волны, способные передавать сигналы, читаемые машинами или компьютерами.
Специалисты в данной области техники поймут, что информация и сигналы могут быть представлены с помощью любой из множества различных технологий и методик. Например, данные, инструкции, команды, информация, сигналы, биты, символы и микросхемы, которые могут быть приведены в качестве примера по всему описанию выше, могут быть представлены напряжениями, токами, электромагнитными волнами, магнитными полями или частицами, оптическими полями или частицами либо любым их сочетанием.
Специалисты в данной области техники дополнительно примут во внимание, что различные иллюстративные логические блоки, модули, схемы и этапы алгоритма, описанные в связи с раскрытыми в данном документе вариантами осуществления, могут быть реализованы как электронные аппаратные средства, вычислительное программное обеспечение либо их сочетания. Чтобы понятно проиллюстрировать эту взаимозаменяемость аппаратных средств и программного обеспечения, различные иллюстративные компоненты, блоки, модули, схемы и этапы были описаны выше в целом на основе их функциональности. Реализована ли эта функциональность в качестве аппаратных средств или программного обеспечения, зависит от конкретного варианта применения и структурных ограничений, накладываемых на систему в целом. Высококвалифицированные специалисты могут реализовать описанную функциональность различными способами для каждого отдельного применения, но такие решения реализации не должны быть интерпретированы как вызывающие отступление от области применения настоящего изобретения.
Различные иллюстративные логические блоки, модули и схемы, описанные в связи с раскрытыми в данном документе вариантами осуществления, могут быть реализованы или выполнены с помощью процессора общего назначения, процессора цифровых сигналов (DSP), специализированной интегральной схемы (ASIC), программируемой пользователем матричной БИС (FPGA) или другого программируемого логического устройства, дискретного логического элемента или транзисторной логики, дискретных компонентов аппаратных средств или любого их сочетания, предназначенного для того, чтобы выполнять описанные в данном документе функции. Процессором общего назначения может быть микропроцессор, но в альтернативном варианте, процессором может быть любой традиционный процессор, контроллер, микроконтроллер или конечный автомат. Процессор также может быть реализован как сочетание вычислительных устройств, к примеру, сочетание DSP и микропроцессора, множество микропроцессоров, один или более микропроцессоров вместе с ядром DSP либо любая другая подобная конфигурация.
Этапы способа или алгоритма, описанные в связи с раскрытыми в данном документе вариантами осуществления, могут быть реализованы непосредственно в аппаратных средствах, в программном модуле, приводимом в исполнение процессором, или в их сочетании. Программный модуль может размещаться в ОЗУ, флэш-памяти, ПЗУ, памяти типа ЭППЗУ, памяти типа ЭСППЗУ, регистрах, на жестком диске, сменном диске, компакт-диске или любой другой форме носителя хранения, известной в данной области техники. Типичный носитель хранения соединяется с процессором, причем процессор может считывать информацию и записывать информацию на носитель хранения. В альтернативном варианте носитель хранения данных может быть встроен в процессор. Процессор и носитель хранения данных могут постоянно размещаться в ASIC. ASIC может постоянно размещаться в пользовательском терминале. В альтернативном варианте процессор и носитель хранения данных могут постоянно размещаться как дискретные компоненты в пользовательском терминале.
Предшествующее описание раскрытых вариантов осуществления предоставлено, чтобы дать возможность любому специалисту в данной области техники создавать или использовать настоящее изобретение. Различные модификации в этих вариантах осуществления будут явными для специалистов в данной области техники, а описанные в данном документе общие принципы могут быть применены к другим вариантам осуществления без отступления от духа и объема изобретения. Таким образом, настоящее изобретение не предназначено, чтобы быть ограниченным показанными в данном документе вариантами осуществления, а должно удовлетворять самой широкой области применения, согласованной с принципами и новыми признаками, раскрытыми в данном документе. В то время как были описаны типичные варианты осуществления, специалистам в области техники будет понятно, что эти и другие изменения в форме и деталях могут быть сделаны здесь без отступления от объема и духа изобретения.
1. Способ защиты конфиденциальности пользователя, содержащий этапы, на которыхформируют первый идентификатор вторичного ключа, связанный с пользователем, на основании ключа и, по меньшей мере, одного параметра, содержащего первую переменную сеанса, связанную с первым сеансом;отправляют упомянутый первый идентификатор вторичного ключа на приложение;формируют первый ключ трафика, связанный с упомянутым первым идентификатором вторичного ключа; иосуществляют безопасную связь с упомянутым приложением с помощью упомянутого первого ключа трафика во время первого сеанса, включая согласование с упомянутым приложением второй переменной сеанса для связи с последующим вторым сеансом.
2. Способ по п.1, в котором упомянутый пользователь связывается с одним и тем же приложением, по меньшей мере, в течение двух сеансов.
3. Способ по п.1, в котором упомянутый пользователь связывается с другим приложением в каждом сеансе в течение, по меньшей мере, двух сеансов.
4. Способ по п.1, в котором упомянутая первая переменная сеанса содержит значение счетчика.
5. Способ по п.1, в котором упомянутая первая переменная сеанса содержит временную отметку.
6. Способ по п.1, в котором упомянутая первая переменная сеанса содержит вывод генератора псевдослучайных чисел.
7. Способ по п.4, в котором упомянутое значение счетчика содержит вывод счетчика приращений, причем упомянутый вывод отличается для каждого сеанса.
8. Способ по п.1, в котором другой параметр, по меньшей мере, одного параметра содержит идентификатор приложения, связанный с упомянутым приложением при связи с упомянутым пользователем.
9. Способ по п.8, в котором упомянутый идентификатор приложения содержит универсальный идентификатор приложения, причем упомянутый универсальный идентификатор приложения используется, когда идентификатор упомянутого приложения при осуществлении связи с пользователем неизвестен пользователю.
10. Способ по п.1, в котором упомянутый этап формирования первого идентификатора вторичного ключа на основании упомянутого, по меньшей мере, одного параметра содержит этап, на котором применяют хэш-функцию к упомянутому, по меньшей мере, одному параметру.
11. Способ по п.1, в котором упомянутый этап формирования первого идентификатора вторичного ключа на основании упомянутого, по меньшей мере, одного параметра содержит этап, на котором соединяют, по меньшей мере, один из упомянутого, по меньшей мере, одного параметра с выводом хэш-функции, примененной, по меньшей мере, к одному из упомянутого, по меньшей мере, одного параметра.
12. Способ защиты конфиденциальности пользователя во время связи в системе, имеющей сервер ключей, при этом упомянутый способ содержит этапы, на которыхпринимают от пользователя первый идентификатор вторичного ключа, сформированный из ключа и, по меньшей мере, одного параметра, содержащего первую переменную сеанса, связанную с первым сеансом;передают упомянутый первый идентификатор вторичного ключа на упомянутый сервер ключей;принимают от упомянутого сервера ключей информацию, связанную с упомянутым пользователем; ииспользуют упомянутую информацию для осуществления безопасной связи с упомянутым пользователем во время первого сеанса, включая согласование с пользователем второй переменной сеанса для осуществления связи с последующим вторым сеансом.
13. Способ по п.12, в котором упомянутая информация, связанная с упомянутым пользователем, содержит вторичный ключ, и упомянутый вторичный ключ используется для связи с упомянутым пользователем.
14. Способ по п.13, в котором упомянутый вторичный ключ, принятый от упомянутого сервера ключей, формируется на основании, по меньшей мере, одного из упомянутого, по меньшей мере, одного параметра.
15. Способ по п.12, в котором упомянутый первый идентификатор вторичного ключа формируется из упомянутого, по меньшей мере, одного параметра посредством применения хэш-функции к упомянутому, по меньшей мере, одному параметру.
16. Способ по п.12, в котором упомянутая первая переменная сеанса содержит значение счетчика.
17. Способ по п.12, в котором другой параметр, по меньшей мере, одного параметра дополнительно содержит идентификатор приложения, связанный с приложением, запрашиваемым упомянутым пользователем.
18. Способ по п.17, в котором упомянутый сервер ключей выполнен с возможностью не предоставлять упомянутую информацию, если упомянутый идентификатор приложения не соответствует идентификатору приложения, связанному с запрашивающим приложением.
19. Способ по п.12, дополнительно содержащий этапы, на которыхпередают упомянутому серверу ключей упомянутую вторую переменную сеанса, связанную с упомянутым последующим вторым сеансом;принимают от упомянутого сервера ключей дополнительную информацию, связанную с упомянутым пользователем, на основании упомянутой второй переменной сеанса; ииспользуют упомянутую дополнительную информацию для осуществления безопасной связи с упомянутым пользователем во время последующего второго сеанса с упомянутым пользователем.
20. Способ защиты конфиденциальности пользователя, содержащий этапы, на которыхпринимают от пользователя первый идентификатор вторичного ключа, сформированный из ключа и, по меньшей мере, одного параметра, содержащего первую переменную сеанса, связанную с первым сеансом;идентифицируют упомянутый ключ из упомянутого первого идентификатора вторичного ключа;формируют вторичный ключ на основании, по меньшей мере, одного из упомянутого, по меньшей мере, одного параметра;используют во время первого сеанса зашифрованную связь с упомянутым пользователем с помощью упомянутого вторичного ключа; исогласуют с пользователем во время первого сеанса информацию, связанную с последующим вторым сеансом.
21. Способ по п.20, в котором упомянутая первая переменная сеанса содержит значение счетчика, которое увеличивается бесконечно малыми приращениями до или после входа в сеанс связи.
22. Способ по п.21, дополнительно содержащий этап, на которомиспользуют упомянутую информацию для осуществления связи с упомянутым пользователем во время последующего второго сеанса с упомянутым пользователем.
23. Устройство для защиты конфиденциальности пользователя, содержащеегенератор идентификатора вторичного ключа для формирования первого идентификатора вторичного ключа, связанного с пользователем, на основании ключа и, по меньшей мере, одного параметра, содержащего первую переменную сеанса, связанную с первым сеансом;передатчик для отправки упомянутого первого идентификатора вторичного ключа на приложение; игенератор ключей для формирования первого ключа трафика, причем упомянутое устройство безопасно связывается с упомянутым приложением с помощью упомянутого сформированного первого ключа трафика во время первого сеанса, включая согласование с приложением второй переменной сеанса для осуществления связи с последующим вторым сеансом.
24. Устройство по п.23, в котором упомянутое устройство связывается с одним и тем же приложением, по меньшей мере, в течение двух сеансов.
25. Устройство по п.23, в котором упомянутый пользователь связывается с другим приложением в каждом сеансе в течение, по меньшей мере, двух сеансов.
26. Устройство для защиты конфиденциальности пользователя во время связи в системе, имеющей сервер ключей, при этом упомянутое устройство содержитприемник для приема от пользователя первого идентификатора вторичного ключа, сформированного из ключа и, по меньшей мере, одного параметра, содержащего первую переменную сеанса; ипередатчик для передачи упомянутого первого идентификатора вторичного ключа на упомянутый сервер ключей;причем приемник дополнительно выполнен с возможностью принимать от упомянутого сервера ключей информацию, связанную с упомянутым пользователем;и причем упомянутая информация используется упомянутым устройством для осуществления безопасной связи с упомянутым пользователем во время первого сеанса, включая согласование с пользователем второй переменной сеанса для осуществления связи с последующим вторым сеансом.
27. Устройство для защиты конфиденциальности пользователя, содержащееприемник для приема от пользователя первого идентификатора вторичного ключа, сформированного из ключа и, по меньшей мере, одного параметра, содержащего первую переменную сеанса;процессор для идентификации упомянутого ключа из упомянутого первого идентификатора вторичного ключа; игенератор для формирования вторичного ключа на основании, по меньшей мере, одного из упомянутого, по меньшей мере, одного параметра;причем упомянутое устройство осуществляет связь с упомянутым пользователем с помощью упомянутого вторичного кл