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

Формула изобретения

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

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

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

- передачу указанного шифрованного сертификата аутентификации на указанный сервер;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- получения, по меньшей мере, одного параметра шифрования;

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

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

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

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

- прием шифрованного сертификата аутентификации от указанного клиентского терминала;

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

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

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

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

- прием шифрованного сертификата аутентификации от указанного клиентского терминала;

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

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

- аутентификацию и выдачу подтверждения аутентификации, если аутентификация прошла успешно, причем указанные операции выполняются в протоколах EAP-TLS или EAP-SSL,

- причем устройство выполнено в интегральном виде с использованием виртуальной машины.

Описание изобретения к патенту

ОБЛАСТЬ ИЗОБРЕТЕНИЯ

Настоящее изобретение относится к области защиты идентификационной информации в сети.

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

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

Изобретение также относится к способу управления множеством модулей безопасности аутентификации.

В рамках изобретения термин «сеть» должен пониматься в самом широком смысле. Этот термин используется, чтобы определять местные компьютерные сети, основанные на модемах асимметричной цифровой абонентской линии и узлах доступа Wi-Fi, общедоступные сети, оборудованные базовыми станциями (UMTS, HSDPA и т.д.), или беспроводные точки доступа (Wi-Fi, WiMax и т.д.), компании или сети коммунального обслуживания, используя LAN, PLAN, WLAN или сети типа MAN.

Точно так же сама эта сеть должна пониматься в самом широком возможном смысле. Это может быть, например, компьютер, управляемый операционной системой. Кроме того, такой компьютер может быть оборудован одним или несколькими интерфейсами связи, описанными во многих стандартах, таких как IEEE 802.3 (стандарт Ethernet), IEEE 802.11 (стандарт Wi-Fi), IEEE 802.16 (стандарт WiMax), IEEE 802.16е (стандарт WiMobile). Сеть может также включать терминалы мобильной связи, такие как мобильные телефоны или персональные помощники.

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

ИЗВЕСТНЫЕ ТЕХНИЧЕСКИЕ РЕШЕНИЯ

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

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

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

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

- управление доступом к уровню OSI (уровень соединения открытых систем n°2) местных сетей. Этот операционный режим, в котором используется протокол РРР (протокол канала связи от точки к точке) и стандарты мобильной связи;

- управление доступом к уровням соединения открытых систем n°3 и 4: IP и UDP/TCP (протокол пользовательских датаграмм и транспортный протокол управления). Этот режим работы, как правило, используется, чтобы создать соединение через VPN (виртуальную частную сеть), например, через протокол аутентификации IKEv2.

Из-за роста проблем безопасности, вызванных интенсивным использованием сетей связи, в частности сетей радиосвязи, IETF ратифицировал стандарт под названием ЕАР (расширяемый протокол аутентификации). Этот стандарт разрешает передачу множества сценариев аутентификации, при этом некоторые из них определены техническими условиями EAP-TLS (RFC 2246), EAP-SIM (RFC 4186) и ЕАР-АКА (RFC 4187).

Протокол EAP-TLS, введенный REC 2246, является прозрачным пакетом протокола TLS (протокол защиты транспортного уровня), который точно определен в документе REC 2716.

Протоколы ЕАР могут быть использованы для управления доступом к MAC (PPP, совместимый с REC 2284, сетью Ethernet и WiFi совместимый с IEEE 802.1x, WiMax, совместимый с IEEE 802.16 и IEEE 802.16е), так же как обслуживание уровня VPN (IKEv2, описанное в документе REC 4306, протокол РРТР соединения от точки к точке, описанный в REC 2637, уровень Cisco L2F двух протоколов, описанных в REC 2341).

TLS является улучшенной неимущественной версией SSL (протокол защищенных сокетов), запатентованный корпорацией Netscape (патент США 5 657 390), которая опубликовала версию 2 в конце 1994 года и версию 3 в ноябре 1996 года.

На фигуре 1 показана стандартная операция по протоколу TLS.

При нормальном использовании сервер сети (301) предлагает удаленному клиенту (как правило, веб-браузеру 201) свой идентификатор (вставленный в сертификационное сообщение 103) в форме сертификата Х509. Клиент анализирует сертификат от сервера и, в частности, проверяет подпись, используя открытый ключ сертификационного центра (К_pubCA), которому он доверяет. Если эта проверка является успешной, клиент извлекает открытый ключ, содержавшийся в сертификате (103, K_pubS), и выбирает случайное число 48 октетов, названное PreMasterSecret (107), которое передается на сервер посредством ключа K_pubS (в сообщении ClientKeyExchange).

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

Когда в сценарии аутентификации используется протокол TLS, например ЕАР-TLS, аутентификация клиента обязательна; эту взаимную процедуру аутентификации обычно называют подтверждением аутентификации клиента. Клиент передает на сервер свой идентификатор в декодированном виде (в сертификационном сообщении 106), то есть через свой сертификат Х509. Он доказывает его подлинность, создавая подпись типа установления связи, которой обмениваются заранее между этими двумя объектами (клиент и сервер) с помощью секретного ключа K_privC . Эта информация передается через сообщение, называемое CertificateVerify (сертификат подтвержден) (108). Сервер проверяет идентификатор клиента с помощью двух операций:

1. Анализа сертификата Х509, представленного клиентом, из которого он, в частности, извлекает свой открытый ключ К_pubC.

2. Проверки правильности подписи, содержащейся в сообщении CertificateVerify, с помощью ключа К_pubC.

Использование протокола TLS вынуждает клиента открывать свой идентификатор на стадии идентификации.

Недостатки известных технических решений

Один недостаток этой методики известных технических решений состоит в том, что протокол EAP-TLS не гарантирует конфиденциальность идентификационной информации клиента.

Действительно, даже при том что протокол EAP-TLS широко используется поставщиками услуг для управления доступом к WLAN (WiFi, WiMax) или VPN (IKEv2 и т.д.), недостаточная защита идентификатора клиента, например, позволяет получить список персонала компании или администрации за пределами стен этих учреждений.

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

Получение идентификатора клиентов в сети, используя протокол EAP-TLS, является пассивной или активной атакой. Тривиальная пассивная атака состоит из прослушивания подтверждений подлинности и отметки списка имеющихся клиентов в сети.

На фигуре 2 описан актив, который использует протокол EAP-TLS. В этом сценарии терминал клиента оборудован интерфейсом WiFi и используется протокол EAP-TLS. Таким образом, он ведет себя как RFID (идентификатор радиочастоты) - электронная метка, которая может считываться на расстоянии до 100 метров и которая позволяет определить присутствие конкретного пользователя.

Узел, доступный хакерам (АР, 301), периодически передает по радио идентификатор SSID, интерпретируемый клиентской станцией как идентификатор разрешенного АР. В соответствии с протоколом IEEE 802.1х начинается сеанс аутентификации. Клиент передает пакет начала операции ЕАР (102), АР посылает сообщение запроса (104) ЕАР-идентификатора, сообщения ответов клиента с ЕАР-идентификатором (104). АР передает сообщение пуска (105) EAP-TLS.

Клиент затем посылает ответ EAP-TLS, который содержит TLS сообщение ClientHello (106). АР хакера посылает сообщение (107) ServerHello, содержащее сертификат, который должен открыть идентификатор сервера аутентификации, которому клиент доверяет.

Эта идентификационная информация может быть получена, заранее прослушивая и анализируя сообщения EAP-TLS, или из знания сертификатов сервера, которые по своей природе не являются конфиденциальными. В соответствии с протоколом TLS сообщение (107) ServerHello не имеет никаких атрибутов безопасности и может быть легко подделано, при условии что вставлен правильный идентификатор сервера. Это сообщение посылают клиенту в сообщении EAP-TLS.request (107). Клиент проверяет сертификат сервера и передает свой идентификатор в ответе EAP-TLS.response, который несет сообщение (108) TLS типа сертификата. Хакер достигает своей цели, получая на расстоянии идентификатор клиента (109).

Это описание классической активной атаки высвечивает главный недостаток этой методики аутентификации, используемой в соответствии с протоколом EAP-TLS, который обязывает клиента открывать свой идентификатор.

КРАТКОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

- передачу указанного шифрованного сертификата аутентификации на указанный сервер;

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

- декодирование указанного шифрованного сертификата аутентификации из указанного одного параметра шифрования;

аутентификацию и передачу подтверждения аутентификации, если аутентификация прошла успешно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В одном конкретном варианте воплощения изобретения указанный способ осуществлен в протоколе TLS и/или SSL.

По другому оригинальному варианту воплощения указанный способ осуществлен в протоколе ЕАР.

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

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

По настоящему изобретению такой способ включает следующие стадии:

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

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

- передачу указанного шифрованного сертификата аутентификации на указанный сервер.

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

Изобретение также относится к устройству шифрования идентификатора клиентского терминала, у которого есть сертификат аутентификации, во время аутентификации указанного терминала сервером аутентификации.

По настоящему изобретению такое устройство выполняет следующие стадии:

- поиск, по меньшей мере, одного параметра шифрования;

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

- передачу указанного шифрованного сертификата аутентификации на указанный сервер.

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

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

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

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

В соответствии с изобретением этот способ включает следующие стадии:

- прием шифрованного сертификата аутентификации от указанного клиентского терминала;

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

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

- аутентификацию и выдачу подтверждения, если аутентификация прошла успешно.

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

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

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

- прием шифрованного сертификата аутентификации от указанного клиентского терминала;

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

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

- аутентификацию и выдачу подтверждения, если аутентификация прошла успешно.

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

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

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

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

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

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

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

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

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

ПЕРЕЧЕНЬ ЧЕРТЕЖЕЙ

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

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

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

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

- фигура 4 иллюстрирует структуру модуля безопасности;

- фигура 5 иллюстрирует практическое воплощение приложения EAP-TLS в плате для интегральных схем типа карты Java;

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

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

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

- фигура 9 иллюстрирует обмен сообщениями между NAS и сервером аутентификации RADIUS, оборудованным модулем безопасности EAP-TLS;

- фигура 10 раскрывает понятие идентификатора сеанса (сессия_ID), созданного, используя определенные атрибуты пакета запроса доступа и его использования для обработки сообщения ЕАР конкретным модулем безопасности.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

Принцип изобретения

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

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

В процессе аутентификация EAP-TLS сообщения обмениваются по протоколу TLS. Во время сеанса связи для аутентификации клиента клиент (201) инициализирует этот сеанс в соответствии с сообщением ClientHello. Сервер отвечает рядом сообщений ServerHello (102), Certificate (103), CertificateRequest (104) и ServerHelloDone (105). Клиент затем посылает Certificate (106), CertificateVerify (107), ClientKeyExchange (108), ChangeCipherSpec (109) и Finished (окончание сообщений) (110).

Сообщение Certificate (106) является шифрованной формой клиентского сертификата. Более точно и в соответствии с протоколом TLS, содержание сообщения представляет собой последовательность сертификатов, из которых первый приписан клиенту, а следующие сертификаты (присутствующие в данном выборе) связаны с одним или несколькими сертификационными центрами.

Посредством примера далее описан практический способ вычисления используемого ключа (KeyClientCertificate), чтобы закодировать клиентский сертификат (106). Однако для этой операции могут использоваться другие способы, основанные на секретных формулах, которые затрудняют атаки хакеров.

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

Общедоступный секретный ключ MasterSecret вычисляется из параметра PreMasterSecret и двух других случайных чисел (ClientRandom и ServerRandom), обмениваемых в сообщениях ClientHello (101) и ServerHello (102). Ключ MasterSecret поэтому может быть определен как:

MasterSecret=

PRF(PreMasterSecret, "mastersecret", Clientrandom | ServerRandom).

Знак | в этом случае определяет операцию конкатенации. Затем на стадии аутентификации получаются другие ключи шифрования, используя параметр MasterSecret и ярлык (ряд символов ASCII). Эти другие ключи также используют функцию PRF:

Ключи=

PRF (MasterSecret, Label, ServerRandom|ClientRandom)

Согласно изобретению ключ шифрования KeyClientCertificate получен из соотношения типа (106):

KeyClientCertificate=

F(PreMasterSecret, ServerRandom, ClientRandom, Otherparameters)

В этом случае F является функцией, которая использует PreMasterSecret, ServerRandom, ClientRandom и другие параметры вычисления (OtherParameters). Например, можно использовать следующую функцию:

KeyClientCertificate=

PRF(MasterSecret, "clientcertificate", ClientRandom | ServerRandom)

Таким образом, клиент защищает свой идентификатор, шифруя свой сертификат Х509, используя, например, алгоритм шифрования и ключ KeyClientCertificate, связанный с этим алгоритмом шифрования, например RC4 или AES в режиме счетчика. В соответствии с условиями протокола TLS величины (функции MD5 и SHA1), используемые в сообщениях, таких как CertificateVerify (108) и Finished (110, 112), вычисляются, принимая во внимание содержание шифрованного клиентского сертификата (106). Фактически этот сертификат появляется в сообщении Certificate (сертификат) в кодированном виде (106).

Сервер получает сообщения *Certificate (106) и CertificateVerify (107), ClientKeyExchange (108), ChangeCipherSpec (109) и Finished (110). Он декодирует значение PreMasterSecret, содержащееся в сообщении ClientKeyExchange (108), используя свой секретный ключ K_privs. Он удаляет ключ, защищающий клиентский сертификат (106), используя декодированную величину PreMasterSecret, функцию декодирования, аналогичную функции, применяемой клиентом, чтобы получить ключ KeyClientCertificate. В одном конкретном варианте воплощения изобретения, к которому относится функция TLS PRF, используется следующая формула:

KeyClientCertificate=

PRF (MasterSecret, client certificate, ClientRandom | ServerRandom)

Сервер затем может декодировать сертификат клиента.

Сервер завершает стадию открытия сеанса TLS, формируя два сообщения ChangeCipherSpec (111) и Finished (112).

Следует принимать во внимание то обстоятельство, что фактически сообщение PreMasterSecret может быть декодировано только сервером, поскольку только сервер имеет секретный ключ, который может декодировать это сообщение. Например, в случае EAP-TLS сообщение PreMasterSecret шифрован клиентом, используя открытый ключ сервера K_pubs , посланный клиенту сервером при передаче сертификата (103). При этом только держатель секретного ключа K_privs может декодировать сообщения, шифрованные этим открытым ключом K_pubs.

Таким образом, идентификатор клиента держится в секрете, и только сервер может декодировать этот идентификатор.

Таким образом, здесь описывается вариант способа шифрования идентификатора клиента, используемого как часть взаимного процесса аутентификации по протоколу EAP-TLS. Таким образом, клиент больше не разделяет свой "декодированный" идентификатор с сетью. Этот идентификатор зашифрован, и только сервер с соответствующей информацией декодирования может идентифицировать клиента для аутентификации. Действительно, чтобы найти ключ декодирования KeyClientCertificate, сервер должен иметь ту же самую информацию, что и у клиента. В целом, эта информация является информацией, которая используется для нахождения ключа шифрования, используя функцию "F". В конкретном варианте воплощения изобретения, применимом к EAP-TLS, у сервера должны быть те же самые параметры для функции PRF, как и параметры, используемые клиентом: MasterSecret, сертификат клиента, ClientRandom и ServerRandom.

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

Описание модуля безопасности

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

Термин модуль безопасности используется для определения интегральной схемы (101), обычно характеризуемой как печатная плата, например компонент ST22, поставляемый компанией C-Microelectronics (зарегистрированный торговый знак) и доступный в различных формах, таких как поливиниловые платы (платы для интегральных схем, СИМ-карты и т.д.), интегрированные в блоки памяти с разъемом USB или в ММС (мультимедийная плата).

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

Более точно, такой модуль безопасности имеет центральный процессор (201), ROM, который хранит код операционной системы (202), оперативную память (203) и энергонезависимую память (NVR, 204), используемую как запоминающее устройство, аналогичное жесткому диску, которое содержит, например, интегрированное программное обеспечение TLS или EAP-TLS. Системная шина (200) служит для соединения различных частей безопасного модуля. Связь с внешним миром (301) осуществляется через порт ввода-вывода (205), отвечающий современным стандартам, таким как ISO 7816, USB, ISO 7816-12, ММС, IEEE 802.3, IEEE 802.11 и т.д.

Карты Java могут формировать определенный класс модуля безопасности. В настоящее время можно загружать и работать с этими компонентами программ, которые соответствуют условиям протокола TLS, в режиме сервера и клиента. Следует отметить, что такое программное обеспечение известно под именем OpenEapSmartCard (открытая смарт-карта). В научной литературе уже описано создание карт Java для клиента и сервера для работы по протоколу EAP-TLS. Способ защиты идентификатора, уже описанный выше, может быть легко применен квалифицированным специалистом, используя программное обеспечение для карты Java на стороне клиенте (или сервера) по протоколу EAP-TLS.

На фигуре 5 представлено практическое воплощение приложения EAP-TLS в контексте карты Java.

Такой компонент (100) обычно имеет интерфейс связи, соответствующий стандарту (201) Международной организации по стандартизации (ISO 7816), интегрированную виртуальную машину Java (202) и ряд классов Java (203), определенный Форумом карты Java, который, в частности, разрешает использование библиотеки функций шифрования (204). Приложение (300) EAP-TLS определяется как ряд модулей Java.

Класс EAPEngineClass (301) обеспечивает четыре основные услуги:

- управление (402) аккредитивами держателя карты, то есть уязвимые данные, такие как персональный ключ RSA или сертификат Х509, хранящиеся в энергонезависимой памяти (401);

- персонализацию (404) модуля безопасности, то есть все операции, требуемые для записи данных держателя карты в памяти компонента;

- управление безопасностью (403) из платы для интегральных схем, использование которой защищено, например, кодом, связанным с механизмом блокировки доступа после трех неправильных попыток;

- интерфейс с сетью (405), который анализирует полученные пакеты ЕАР и передает их для обработки способом EAP-TLS.

Способ аутентификация EAP-TLS выполняется модулем Method.class (303). Этот модуль инициализируется данными, связанными с определенным контекстом (сертификат сертификационного центра, центр связи, сертификат клиента, персональный ключ RSA и т.д.), использующий процедуру (501), в результате которой аргумент представляет собой объект credential.class (302) Java.

Сообщения ЕАР (600), анализируемые сетевым интерфейсом (405), обрабатываются процедурой ProcessEap (502) модуля Method.class module (303). Интерфейс Java Auth.class (304) обеспечивает логическую связь между EapEngine.class (301) и Method. class (303).

Клиентский модуль безопасности

На фигуре 6 показан модуль безопасности (201), который содержит клиентское программное обеспечение EAP-TLS (101). Эта программа выполняет протокол TLS, который она получает через порт ввода-вывода (фигура 4, 205) в виде сообщений EAP-TLS и создает соответствующие ответы. Кроме того, модуль хранит сертификат, по меньшей мере, одного сертификационного центра (102) и его собственный открытый ключ (103) RSA. Идентификатор модуля, т.е. сертификат клиента (104), также надежно сохранен. Однако этот сертификат никогда не передается внешнему миру в декодированном виде. Общий (107) и частный (106) ключи RSA также управляются модулем безопасности. В конце протокола EAP-TLS ключ MSK (108) доступен для объекта, используя модуль, как правило, в виде операционной системы.

Диалог аутентификации EAP-TLS будет описан более подробно с точки зрения клиентского модуля безопасности (201), используя протокол защиты идентификатора по настоящему изобретению.

Узел доступа (401) извещает клиента о вхождении в новый сеанс аутентификации, посылая сообщение EAP-Identity.request (301). Модуль безопасности вставляет свой идентификатор (EAP-ID) в сообщение EAP-Identity.response (302). Это рекомендуется, поскольку без этой операции действие будет рассматриваться как ограничение того, что этот идентификатор предоставляет информацию о сервере аутентификации, а не о клиенте. Сервер аутентификации передает пакет EAP-TLS.start (303), который инициирует сеанс EAP-TLS. В ответ на это событие клиент инициирует сообщение EAP-TLS, несущее пакет TLS типа ClientHello (304).

В соответствии с описанным выше протоколом TLS сервер посылает ряд сообщений (ServerHello, Certificate, CertificateRequest, ServerHelloDone), которые, в частности, определяют сертификат сервера, открытый ключ сервера, сертификационный центр (СА), сертификат и тип (типы) клиентских сертификатов, признанных сервером.

После получения сообщения EAP-TLS (305) клиент анализирует достоверность сертификата сервера, извлекает соответствующий открытый ключ, выбирает случайную величину PreMasterSecret и шифрует эту величину (с открытым ключом сервера) в сообщении ClientKeyExchange. Сертификат клиента шифруется описанным выше ключом KeyClientCertificate по способу защиты идентификатора. Ряд сообщений TLS (307) Certificate, ClientkeyExchange, CertificateVerify, Finished вставляются в пакет EAP-TLS и передаются серверу.

Сервер проверяет этот список сообщений и регистрирует правильное завершение этой операции сообщениями ChangeCipherSpec и Finished (308), формируемыми в пакете EAP-TLS. Клиент подтверждает получение (308) принятием EAP-TLS (309).

Сервер заканчивает сеанс EAP-TLS в соответствии с сообщением EAP.success (310). После получения этого подтверждения клиент вычисляет главный секретный ключ (MSK) (108). Последний делается доступным для операционной системы клиента через конкретный модуль безопасности (311).

Выполнение программы клиента TLS или EAP-TLS (101) модулем безопасности (201), оборудованным согласно изобретению механизмом защиты идентификатора, обеспечивает следующие преимущества:

- сертификат сервера (305) проверяется в безопасной компьютерной среде;

- клиентское программное обеспечение (101) сообщает свой шифрованный (106) идентификатор (104) только объекту сервера, которому он доверяет и который является единственным объектом, который способен декодировать эту информацию;

- клиент подтверждает свое решение путем подписи, основанной на его персональном ключе RSA K _privc (106), содержащемся в сообщении CertificateVerify (307).

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

Модуль безопасности сервера

На фигуре 7 представлен модуль безопасности (401), который содержит программу EAP-TLS сервера (101). Эта программа выполняет протокол TLS, при этом она получает через порт ввода-вывода (фигура 4, 205) пакеты EAP-TLS и создает соответствующие сообщения. Кроме того, модуль хранит сертификат, по меньшей мере, одного сертификационного центра (102) и его открытый ключ RSA (103). Сертификат сервера (107) и его открытый (109) и персональный (108) ключи RSA также контролируются модулем безопасности. В конце протокола EAP-TLS ключ MSK (108) доступен для объекта, используя, например, модуль RADIUS сервера аутентификации.

Ниже описывается диалог аутентификация EAP-TLS с точки зрения модуля безопасности сервера (101). Этот модуль физически или логически связан с сервером аутентификации, например, типа RADIUS (201) с или любым другим устройством, используя логический объект сервера ЕАР. Сервер ЕАР получает сообщение ЕАР-Identity.request (301), которое отмечает инициализацию сеанса ЕАР. Сервер посылает сообщение EAP-TLS.start (303), которое указывает на начало сеанса EAP-TLS.

Удаленный клиент посылает пакет EAP-TLS (305), который включает сообщение ClientHello (304). Затем сервер посылает ряд сообщений (ServerHello, Certificate, CertificateRequest, ServerHelloDone). После получения сообщения (305) клиент анализирует достоверность сертификата сервера, извлекает соответствующий открытый ключ, выбирает случайную величину PreMasterSecret и шифрует эту величину (с открытым ключом сервера) в сообщении ClientKeyExchange. Сертификат клиента (307) зашифрован с ключом KeyClientCertificate, описанным выше. Ряд сообщений TLS (306) Certificate, ClientkeyExchange, CertificateVerify, Finished вставляются в пакет EAP-TLS и передается на сервер.

Сервер проверяет этот список сообщений, в частности он находит величину PreMasterSecret, используя свой ключ K_privs. Затем он вычисляет KeyClientCertificate и получает декодированный сертификат от клиента. Сервер регистрирует правильность завершения этой операции ChangeCipherSpec и сообщение Finished (завершено) (308), формируемое в пакете EAP-TLS.

Клиент подтверждает прием сообщений ChangeCipherSpec и завершение операции (308) путем квитирования EAP-TLS (309). Модуль безопасности заканчивает сеанс EAP-TLS сообщением (310) EAP-Success и вычисляет главный секретный ключ MSK (108). Последний становится доступным для операционной системы сервера (201) посредством конкретной команды (311) модуля безопасности.

Выполнение программы клиента TLS или EAP-TLS (101) модулем безопасности (201), оборудованным согласно изобретению механизмом защиты идентификатора, обеспечивает следующие преимущества:

- модуль безопасности сервера является единственным узлом, который знает и может использовать секретный ключ k_privs (108) - единственный объект, который знает идентификатор клиента;

- кроме того, идентификатор клиента удостоверен сообщением CertificateVerify (306);

- проверка достоверности этого идентификатора выполняется способом шифрования в последнем сообщении, Finished (309), выдаваемом сервером.

Когда сервер аутентификации, например, типа RADIUS использует модуль безопасности сервера, этот модуль делает доступным ключ (109) MSK, используемый, например, для защиты безопасности связи между узлом доступа и клиентской парой беспроводной сети.

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

Реализация модулей безопасности в инфраструктуре аутентичности

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

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

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

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

Описание инфраструктуры

На фигуре 8 представлена инфраструктура RADIUS, в которой используется способ защиты идентификатора согласно изобретению. Ряд клиентов (201, 202, 203) по выбору оборудованы модулями безопасности (101, 102, 103) и управляются серверами администрации сети (NAS) (301, 302, 303), расположенными, например, в узлах доступа этой сети. Каждый клиент соединен через сеть Интернет 401 с одиночным сервером аутентификации RADIUS (501) с помощью программного обеспечения (502), выполняемым компьютерной системой, снабженной операционной системой. Этот сервер RADIUS дополнительно обеспечивает обмен информацией через физические и/или логические интерфейсы 503 с множеством модулей безопасности (601, 602, 603) сервера.

В настоящее время имеется много бесплатных программ, таких как OPENRADIUS или FREERADIUS, которые обеспечивают обслуживание аутентификации инфраструктуры RADIUS. Модули безопасности могут быть интегрированы в эти программы физически (503) и/или используются интерфейсы на основе программных средств, поддерживаемые многими операционными системами, такими как USB или PC/SC (смарт-карта персонального компьютера).

Обмен сообщениями

На фигуре 9 представлен пример обмена информацией в виде сообщений между NAS, представленным в виде узла доступа (101), сервером аутентификации RADIUS (201) и модулем безопасности EAP-TLS (301). Последний включает, как описано выше, персональный ключ RSA и сертификат Х509 от сертификационного центра.

Термин сеанс RADIUS (401) используется для обозначения обмена пакетами данных между NAS и сервером аутентификации RADIUS. Эти пакеты несут информацию обмена между клиентом ЕАР и сервером ЕАР.

Что касается сервера RADIUS, то сеанс начинается с приема сообщения (601) ЕАР-Identity.response, которое включает пакет с запросом о доступе (501) и окончание уведомления, как правило, EAP-Success (610) в пакете ввода доступа (510).

Сообщение EAP-Identity.response передается пакетом с запросом о доступе RADIUS (501). Сообщение с запросом о доступе EAP-TLS просит, чтобы сообщение под названием EAP-TLS.start (602) было бы передано на узел доступа в пакете вызова доступа RADIUS (502). Сообщение EAP-TLS, формирующее элемент протокола TLS ClientHello (603), передается пакетом с запросом о доступе RADIUS (503).

Пакет TLS, содержащий ряд сообщений ServerHello, сертификат, CertificateRequest и сообщение ServerHelloDone, как правило, по правилам протокола EAP-TLS разбивается на два фрагмента (604), (606). Каждый фрагмент передается в пакете вызова доступа RADIUS (504), (506). Первый фрагмент вводится в сообщение (605) EAP-TLS, передаваемое пакетом RADIUS (505). После приема второго и последнего фрагмента (606) клиент (который желает быть идентифицированным с подтверждением его подлинности) анализирует повторно собранное сообщение.

Во время приема второго фрагмента (606) клиент анализирует достоверность сертификата сервера, извлекает соответствующий открытый ключ, выбирает случайную величину PreMasterSecret и шифрует эту величину (с открытым ключом сервера) в сообщении ClientKeyExchange. Сертификат клиента шифрован с ключом KeyClientCertificate, описанным выше. Ряд сообщений TLS Certificate, ClientKeyExchange, CertificateVerify и Finished вставляется в пакет EAP-TLS (607), затем в пакет с запросом о доступе RADIUS (507) и посылается в сервер.

Сервер проверяет этот список сообщений и, в частности, находит величину PreMasterSecret, вычисляет KeyClientCertificate и получает декодированный сертификат клиента. Если эта операция прошла успешно, формируются сообщения ChangeCipherSpec и Finished в пакете EAP-TLS, затем сообщение RADIUS (508) вызова доступа.

Сообщение EAP-TLS (609) передается в сообщении (509) с запросом о доступе RADIUS.

Модуль безопасности затем указывает на успех аутентификации через сообщение EAP-success. Сервер RADIUS считывает ключ MSK по команде (611) и создает последнее сообщение ввода доступа RADIUS (510), которое, в частности, включает эти две половины MS-MPPE-sendkey и MS-MPPE-recvkey ключа MSK.

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

На фигуре 10 содержание пакета RADIUS представлено в виде запроса-доступа. Такие сообщения передаются множеством NAS (сервер доступа к сети) на сервер аутентификации RADIUS (фигура 8, 501). Пакет с запросом о доступе среди другой информации включает ответ ЕАР. Сервер RADIUS, который получает этот пакет, в ответ создает сообщения типа вызова доступа, доступ-доступ, доступ-отмена, формируя в целом запрос ЕАР или уведомление.

Содержание пакета с запросом о доступе (101) будет далее описано более подробно как транспортируемые IP и UDP (протокол пользовательских датаграмм) пакеты связи, которые имеют две части: заголовок (102) и список атрибутов 103).

Заголовок показывает код сообщения (201) или запрос доступа в нашем примере, ярлык (202) так, что величина ответа равна величине запроса, длине пакета (203) и случайному октетному числу 16 (204).

Сообщение RADIUS включает переменное число атрибутов (205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215), которые идентифицированы в фигуре 10 названием, определенным стандартами REC 2865 и REC 3559.

С точки зрения сервера RADIUS сеанс идентифицирован списком информации, связанной с удаленным клиентом (205, 208), и списком информации, связанной с администратором сети (NAS), используемым клиентом (206, 207, 209, 210, 213). Каждый сеанс связан с уникальным идентификатором (логин сеанса), полученным конкатенацией атрибутов, включенных в сообщение с запросом о доступе. В качестве примера мы можем создать значение логина сеанса (301) конкатенацией двух следующих атрибутов:

Логин сеанса=NAS-идентификатор | идентификатор вызывающей станции.

Идентификатор NAS (209) (атрибут RADIUS номер 32) является уникальным идентификатором NAS, присвоенным поставщиком оборудования или администратором сети.

"Логин вызывающей станции" (208) (атрибут RADIUS, номер 31) является уникальным идентификатором клиента, например уникальный адрес MAC используемого коммутатора сети.

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

Сообщение ЕАР формируется в функции его размера одним или несколькими атрибутами (214), чья полезная длина составляет 254 октета.

Программное обеспечение сервера RADIUS проверяет правильную величину атрибута (215), при этом HMAC-MD5 защищается секретным ключом (именуемым секретом RADIUS).

Если эта операция прошла успешно, сообщение ЕАР собирается повторно и затем посылается в модуль безопасности (501), связанный с сеансом RADIUS, идентифицированный (301). Следовательно, модуль безопасности сервера, использующий способ защиты идентификатора согласно изобретению, может обеспечить идентификатор клиентского терминала на сервер RADIUS с тем, чтобы получить подтверждение аутентификации от этого сервера. В дальнейшем, когда каждый модуль аутентификации управляет самое большее одним сеансом, максимальное число сеансов аутентификации, которые управляются одновременно программой сервера RADIUS, равно числу модулей безопасности.

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