СПОСОБ И АППАРАТ ДЛЯ АУТЕНТИФИКАЦИИ ИДЕНТИФИКАЦИОННОЙ ИНФОРМАЦИИ, УСТРОЙСТВО, МИКРОСХЕМА, НОСИТЕЛЬ ДЛЯ ХРАНЕНИЯ ИНФОРМАЦИИ И ПРОГРАММА Российский патент 2023 года по МПК H04L9/08 H04L9/32 

ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННУЮ ЗАЯВКУ

[0001] Настоящая заявка испрашивает приоритет по заявке на патент Китая № 202011569219.5, поданной 26 декабря 2020 г. и озаглавленной "СПОСОБ И АППАРАТ ДЛЯ АУТЕНТИФИКАЦИ ИДЕНТИФИКАЦИОННОЙ ИНФОРМАЦИИ, УСТРОЙСТВО, МИКРОСХЕМА, НОСИТЕЛЬ ДЛЯ ХРАНЕНИЯ ИНФОРМАЦИИ И ПРОГРАММА", раскрытие которой в полном объеме включено в настоящий документ посредством ссылки.

ОБЛАСТЬ ТЕХНИКИ

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

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

[0003] В сети связи инициатор запроса (Requester, REQ) может получить доступ к сети через контроллер доступа при аутентификации (Authentication Access Controller, AAC). В некоторых случаях, когда требуется высокий уровень безопасности, контроллер доступа при аутентификации должен выполнять аутентификацию по идентификационной информации инициатора запроса, а инициатор запроса также должен выполнять аутентификацию по идентификационной информации контроллера доступа при аутентификации, чтобы гарантировать, что инициатор запроса, обращающийся к сети, принадлежит легитимному пользователю, а сеть, к которой обращается инициатор запроса, является легитимной сетью. Кроме того, для двухточечной передачи в блокчейн-технологии также необходимо установить доверительные отношения между различными узлами, что также очень важно для аутентификации идентификационной информации узлов.

[0004] В процессе выполнения взаимной аутентификации идентификационной информации (Mutual Identity Authentication, MIA) между инициатором запроса и контроллером доступа при аутентификации для аутентификации идентификационной информации обе стороны должны предоставить свою собственную идентификационную информацию. Однако такая идентификационная информация обычно содержит личную и конфиденциальную информацию, такую как идентификационные номера, домашние адреса, информация о банковской карте, информация о географическом местоположении и информация об аффилированном учреждении. Кроме того, в процессе практического применения такую идентификационную информацию, как правило, включают в физический цифровой сертификат и цифровой сертификат используют в качестве физического идентификационного сертификата.

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

РАСКРЫТИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

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

[0007] Согласно первому аспекту в варианте осуществления настоящего раскрытия предложен способ аутентификации идентификационной информации. Этот способ включает следующие операции.

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

[0009] Контроллер доступа при аутентификации отправляет первое сообщение с запросом аутентификации на первый сервер аутентификации (Authentication Server, AS), которому доверяет контроллер доступа при аутентификации. Первое сообщение с запросом аутентификации включает в себя зашифрованный текст идентификационной информации инициатора запроса и зашифрованный текст идентификационной информации контроллера доступа при аутентификации, и зашифрованный текст идентификационной информации контроллера доступа при аутентификации генерируют путем использования открытого ключа сертификата шифрования для шифрования подлежащих шифрованию данных, включающих в себя цифровой сертификат контроллера доступа при аутентификации и второе одноразовое случайное защитное число.

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

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

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

[0013] Инициатор запроса верифицирует первую цифровую подпись путем использования открытого ключа второго сервера аутентификации и, если верификация успешна, инициатор запроса расшифровывает зашифрованный текст первой информации о результате аутентификации путем использования второго одноразового случайного защитного числа, чтобы получить первую информацию о результате аутентификации, определяет результат аутентификации идентификационной информации контроллера доступа при аутентификации в соответствии с первым результатом верификации в первой информации о результате аутентификации и, когда инициатор запроса определяет, что результат аутентификации идентификационной информации контроллера доступа при аутентификации: «легитимен», отправляет четвертое ответное сообщение об аутентификации на контроллер доступа при аутентификации.

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

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

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

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

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

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

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

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

[0022] Первая часть для верификации выполнена с возможностью верификации второй цифровой подписи путем использования открытого ключа первого сервера аутентификации.

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

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

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

[0026] Первая часть для определения выполнена с возможностью определения результата аутентификации идентификационной информации инициатора запроса в соответствии со вторым результатом верификации во второй информации о результате аутентификации.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0040] Первая часть для верификации выполнена с возможностью верификации третьей цифровой подписи путем использования открытого ключа первого сервера аутентификации.

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

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

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

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

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

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

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

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

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

[0050] Либо инициатор запроса, в котором установлена микросхема, выполнен с возможностью осуществления этапов, выполняемых инициатором запроса в способе аутентификации идентификационной информации, как описано в первом аспекте.

[0051] Либо первый сервер аутентификации, в котором установлена микросхема, выполнен с возможностью осуществления этапов, выполняемых первым сервером аутентификации в способе аутентификации идентификационной информации, как описано в первом аспекте.

[0052] Либо второй сервер аутентификации, в котором установлена микросхема, выполнен с возможностью осуществления этапов, выполняемых вторым сервером аутентификации в способе аутентификации идентификационной информации, как описано в первом аспекте.

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

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

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

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

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

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

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

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

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

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

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

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

[0064] На ФИГ. 1 представлена принципиальная схема способа аутентификации идентификационной информации согласно варианту осуществления настоящего раскрытия.

[0065] На ФИГ. 2 представлена принципиальная схема способа согласования ключа шифрования сообщения между инициатором запроса (Requester, REQ) и контроллером доступа при аутентификации (Authentication Access Controller, AAC) согласно варианту осуществления настоящего раскрытия.

[0066] На ФИГ. 3 представлена принципиальная схема способа аутентификации идентификационной информации в случае отсутствия роуминга согласно варианту осуществления настоящего раскрытия.

[0067] На ФИГ. 4 представлена принципиальная схема еще одного способа аутентификации идентификационной информации в случае отсутствия роуминга согласно варианту осуществления настоящего раскрытия.

[0068] На ФИГ. 5 представлена принципиальная схема способа аутентификации идентификационной информации в случае наличия роуминга согласно варианту осуществления настоящего раскрытия.

[0069] На ФИГ. 6 представлена принципиальная схема еще одного способа аутентификации идентификационной информации в случае наличия роуминга согласно варианту осуществления настоящего раскрытия.

[0070] На ФИГ. 7 представлена принципиальная схема еще одного способа аутентификации идентификационной информации в случае отсутствия роуминга согласно варианту осуществления настоящего раскрытия, на которой символ «*» представляет необязательное поле или необязательную операцию.

[0071] На ФИГ. 8 представлена принципиальная схема еще одного способа аутентификации идентификационной информации в случае отсутствия роуминга согласно варианту осуществления настоящего раскрытия, на которой символ «*» представляет необязательное поле или необязательную операцию.

[0072] На ФИГ. 9 представлена принципиальная схема еще одного способа аутентификации идентификационной информации в случае наличия роуминга согласно варианту осуществления настоящего раскрытия, на которой символ «*» представляет необязательное поле или необязательную операцию.

[0073] На ФИГ. 10 представлена принципиальная схема еще одного способа аутентификации идентификационной информации в случае наличия роуминга согласно варианту осуществления настоящего раскрытия, на которой символ «*» представляет необязательное поле или необязательную операцию.

[0074] На ФИГ. 11 представлена структурная блок-схема контроллера доступа при аутентификации согласно варианту осуществления настоящего раскрытия.

[0075] На ФИГ. 12 представлена структурная блок-схема инициатора запроса согласно варианту осуществления настоящего раскрытия.

[0076] На ФИГ. 13 представлена структурная блок-схема первого сервера аутентификации (сервера аутентификации, которому доверяет контроллер доступа при аутентификации) согласно варианту осуществления настоящего раскрытия.

[0077] На ФИГ. 14 представлена структурная блок-схема второго сервера аутентификации (сервера аутентификации, которому доверяет инициатор запроса) согласно варианту осуществления настоящего раскрытия.

[0078] На ФИГ. 15 представлена принципиальная структурная схема конструкции электронного устройства согласно варианту осуществления настоящего раскрытия.

[0079] На ФИГ. 16 представлена принципиальная структурная схема конструкции микросхемы согласно варианту осуществления настоящего раскрытия.

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

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

[0081] Технические решения, описанные в вариантах осуществления настоящего раскрытия, могут быть произвольно объединены без возникновения конфликта.

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

[0083] Если в качестве примера использовать существующий в настоящее время сценарий беспроводной связи и мобильной связи, в сценарии, в котором инициатор запроса обращается к беспроводной сети через контроллер доступа при аутентификации, инициатор запроса может представлять собой терминальное устройство, такое как мобильный телефон, персональный цифровой помощник (Personal Digital Assistant, PDA) и планшетный компьютер; а контроллер доступа при аутентификации может представлять собой сетевое устройство, такое как точка беспроводного доступа и беспроводной маршрутизатор. В сценарии, когда инициатор запроса обращается к проводной сети через контроллер доступа при аутентификации, инициатор запроса может представлять собой терминальное устройство, такое как настольный компьютер и ноутбук; а контроллер доступа при аутентификации может представлять собой сетевое устройство, такое как коммутатор и маршрутизатор. В сценарии, в котором инициатор запроса обращается к сети с технологией мобильной связи 4-го/5-го поколения (4G/5G) через контроллер доступа при аутентификации, инициатор запроса может представлять собой терминальное устройство, такое как мобильный телефон и планшетный компьютер, а контроллер доступа при аутентификации может представлять собой устройство со стороны сети, такое как базовая станция. Конечно, настоящее раскрытие также подходит для различных сценариев передачи данных, например, по другим проводным сетям и ближним сетям связи.

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

[0085] Для решения вышеуказанных технических проблем в варианте осуществления настоящего раскрытия предложен способ аутентификации идентификационной информации. Контроллер доступа при аутентификации получает сообщение с зашифрованным текстом идентификационной информации, отправленное инициатором запроса. Сообщение с зашифрованным текстом идентификационной информации включает в себя зашифрованный текст идентификационной информации инициатора запроса и зашифрованный текст идентификационной информации инициатора запроса генерируют путем использования открытого ключа сертификата шифрования для шифрования подлежащих шифрованию данных, включающих в себя цифровой сертификат инициатора запроса и первое одноразовое случайное защитное число. Следовательно, гарантируется безопасность передачи идентификационной информации инициатора запроса между инициатором запроса и контроллером доступа при аутентификации. Затем контроллер доступа при аутентификации отправляет первое сообщение с запросом аутентификации на первый сервер аутентификации (Authentication Server, AS), которому доверяет контроллер доступа при аутентификации. Первое сообщение с запросом аутентификации включает в себя зашифрованный текст идентификационной информации инициатора запроса и зашифрованный текст идентификационной информации контроллера доступа при аутентификации, и зашифрованный текст идентификационной информации контроллера доступа при аутентификации генерируют путем использования открытого ключа сертификата шифрования для шифрования подлежащих шифрованию данных, включающих в себя цифровой сертификат контроллера доступа при аутентификации и второе одноразовое случайное защитное число. Следовательно, гарантируется безопасность передачи идентификационной информации инициатора запроса и идентификационной информации контроллера доступа при аутентификации между контроллером доступа при аутентификации и первым сервером аутентификации. Контроллер доступа при аутентификации принимает первое ответное сообщение об аутентификации, отправленное первым сервером аутентификации. Первое ответное сообщение об аутентификации включает в себя зашифрованный текст первой информации о результате аутентификации, первую цифровую подпись, зашифрованный текст второй информации о результате аутентификации и вторую цифровую подпись, причем зашифрованный текст первой информации о результате аутентификации генерируют путем использования второго одноразового случайного защитного числа для шифрования информации, включающей в себя первую информацию о результате аутентификации, причем первая информация о результате аутентификации включает в себя первый результат верификации для цифрового сертификата контроллера доступа при аутентификации, первая цифровая подпись представляет собой цифровую подпись, сгенерированную путем выполнения вторым сервером аутентификации, которому доверяет инициатор запроса, вычисления по подлежащим подписанию данным, включающим в себя зашифрованный текст первой информации о результате аутентификации, зашифрованный текст второй информации о результате аутентификации генерируют путем использования первого одноразового случайного защитного числа для шифрования информации, включающей в себя вторую информацию о результате аутентификации, причем вторая информация о результате аутентификации включает в себя второй результат верификации для цифрового сертификата инициатора запроса, а вторая цифровая подпись представляет собой цифровую подпись, сгенерированную путем выполнения первым сервером аутентификации вычисления по подлежащим подписанию данным, включающим в себя зашифрованный текст второй информации о результате аутентификации. Следовательно, гарантируется безопасность передачи результатов верификации соответствующих цифровых сертификатов контроллера доступа при аутентификации и инициатора запроса. После приема первого ответного сообщения об аутентификации контроллер доступа при аутентификации верифицирует вторую цифровую подпись путем использования открытого ключа первого сервера аутентификации и после успешной верификации отправляет третье ответное сообщение об аутентификации на инициатор запроса; причем третье ответное сообщение об аутентификации включает в себя зашифрованный текст информации о результате аутентификации, и зашифрованный текст информации о результате аутентификации генерируют путем использования ключа шифрования сообщения для шифрования подлежащих шифрованию данных, включающих в себя зашифрованный текст первой информации о результате аутентификации, первую цифровую подпись и второе одноразовое случайное защитное число. Инициатор запроса расшифровывает зашифрованный текст информации о результате аутентификации путем использования ключа шифрования сообщения, чтобы получить зашифрованный текст первой информации о результате аутентификации, первую цифровую подпись и второе одноразовое случайное защитное число, верифицирует первую цифровую подпись путем использования открытого ключа второго сервера аутентификации, после успешной верификации расшифровывает зашифрованный текст первой информации о результате аутентификации путем использования второго одноразового случайного защитного числа, чтобы получить первую информацию о результате аутентификации, и определяет результат аутентификации идентификационной информации контроллера доступа при аутентификации в соответствии с первым результатом верификации в первой информации о результате аутентификации. Инициатор запроса отправляет четвертое ответное сообщение об аутентификации на контроллер доступа при аутентификации; четвертое ответное сообщение об аутентификации включает в себя зашифрованный текст первого одноразового случайного защитного числа; и зашифрованный текст первого одноразового случайного защитного числа получают путем использования ключа шифрования сообщения для шифрования информации, включающей в себя первое одноразовое случайное защитное число. Контроллер доступа при аутентификации расшифровывает зашифрованный текст первого одноразового случайного защитного числа путем использования ключа шифрования сообщения, чтобы получить первое одноразовое случайное защитное число, расшифровывает зашифрованный текст второй информации о результате аутентификации путем использования первого одноразового случайного защитного числа, чтобы получить вторую информацию о результате аутентификации, и определяет результат аутентификации идентификационной информации инициатора запроса в соответствии со вторым результатом верификации во второй информации о результате аутентификации.

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

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

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

[0089] Сервер аутентификации, которому доверяет контроллер доступа при аутентификации, упоминается как AS-AAC, а сервер аутентификации, которому доверяет инициатор запроса, упоминается как AS-REQ. Сервер аутентификации, которому доверяет контроллер доступа при аутентификации, имеет возможность верификации легитимности цифрового сертификата контроллера доступа при аутентификации; и сервер аутентификации, которому доверяет контроллер доступа при аутентификации, имеет цифровой сертификат, соответствующий требованиям ISO/IEC 9594-8/ITU X.509, другим стандартам или другим техническим системам, и закрытый ключ, соответствующий цифровому сертификату. Сервер аутентификации, которому доверяет инициатор запроса, имеет возможность верификации легитимности цифрового сертификата контроллера доступа при аутентификации; и сервер аутентификации, которому доверяет инициатор запроса, имеет цифровой сертификат, соответствующий требованиям ISO/IEC 9594-8/ITU X.509, другим стандартам или другим техническим системам, и закрытый ключ, соответствующий цифровому сертификату. Сервер аутентификации, которому доверяет контроллер доступа при аутентификации, и сервер аутентификации, которому доверяет инициатор запроса, имеют возможность передачи цифрового сертификата на другие серверы аутентификации для верификации, а также имеют возможность передачи на другие серверы аутентификации информации о результатах верификации цифрового сертификата. Когда сервер аутентификации, которому доверяет контроллер доступа при аутентификации, отличается от сервера аутентификации, которому доверяет инициатор запроса, сервер аутентификации, которому доверяет контроллер доступа при аутентификации, и сервер аутентификации, которому доверяет инициатор запроса, доверяют друг другу и им известны цифровые сертификаты друг друга или открытый ключ в цифровом сертификате. Сервер сертификатов для расшифровки (Certificate Sever-Decrypt, CS-DEC) содержит сертификат шифрования, соответствующий требованиям ISO/IEC 9594-8/ITU X.509, другим стандартам или другим техническим системам, и закрытый ключ, соответствующий сертификату шифрования. Может существовать один или более сертификатов шифрования. Сервер сертификатов для расшифровки может быть независимым сервером или может находиться в сервере аутентификации, которому доверяет контроллер доступа при аутентификации.

[0090] Инициатор запроса может быть конечной точкой, участвующей в процессе аутентификации идентификационной информации, устанавливает соединение с контроллером доступа при аутентификации для предоставления услуг и осуществляет доступ к серверу аутентификации через контроллер доступа при аутентификации. Инициатор запроса имеет цифровой сертификат, соответствующий требованиям ISO/IEC 9594-8/ITU X.509, другим стандартам или другим техническим системам, и закрытый ключ, соответствующий цифровому сертификату, ему известен цифровой сертификат сервера аутентификации, которому доверяет инициатор запроса, или открытый ключ в этом цифровом сертификате, и ему известен сертификат шифрования сервера сертификатов для расшифровки или открытый ключ в этом сертификате шифрования. Контроллер доступа при аутентификации может быть другой конечной точкой, участвующей в процессе аутентификации идентификационной информации, устанавливает соединение с инициатором запроса для предоставления услуг, осуществляет доступ к инициатору запроса и выполнен с возможностью непосредственного обращения к серверу аутентификации, которому доверяет контроллер доступа при аутентификации. Контроллер доступа при аутентификации имеет цифровой сертификат, соответствующий требованиям ISO/IEC 9594-8/ITU X.509, другим стандартам или другим техническим системам, и закрытый ключ, соответствующий этому цифровому сертификату, ему известен цифровой сертификат сервера аутентификации, которому доверяет контроллер доступа при аутентификации, или открытый ключ в этом цифровом сертификате, и ему известен сертификат шифрования сервера сертификатов для расшифровки или открытый ключ в этом сертификате шифрования.

[0091] Ниже, в сочетании с фиг. 1, описан способ аутентификации идентификационной информации, предложенный в вариантах осуществления настоящего раскрытия. Этот способ включает следующие этапы.

[0092] На этапе S101 контроллер доступа при аутентификации получает сигнал REQInit, отправленный инициатором запроса.

[0093] Сигнал REQInit включает в себя зашифрованный текст EncPub_{AS_REQ} идентификационной информации инициатора запроса. EncPub_{AS_REQ} генерируется инициатором запроса путем использования открытого ключа сертификата шифрования для шифрования подлежащих шифрованию данных, включающих в себя цифровой сертификат Cert_REQ инициатора запроса и первое одноразовое случайное защитное число. Следовательно, во время передачи идентификационной информации между инициатором запроса и контроллером доступа при аутентификации идентификационную информацию инициатора запроса подвергают конфиденциальной обработке, чтобы предотвратить раскрытие идентификационной информации инициатора запроса во время осуществления доступа к сети. В настоящем раскрытии объект, подлежащий шифрованию, упоминается как подлежащие шифрованию данные.

[0094] На этапе S102 контроллер доступа при аутентификации отправляет сигнал AACVeri на сервер аутентификации, которому доверяет контроллер доступа при аутентификации.

[0095] Сигнал AACVeri включает в себя EncPub_{AS_REQ} и зашифрованный текст EncPub_{AS_AAC} идентификационной информации контроллера доступа при аутентификации. EncPub_{AS_AAC} генерируется контроллером доступа при аутентификации путем использования открытого ключа сертификата шифрования для шифрования подлежащих шифрованию данных, включающих в себя цифровой сертификат Cert_AAC контроллера доступа при аутентификации и второе одноразовое случайное защитное число. Следовательно, во время передачи идентификационной информации между контроллером доступа при аутентификации и сервером аутентификации, которому доверяет контроллер доступа при аутентификации, соответствующую идентификационную информацию инициатора запроса и контроллера доступа при аутентификации подвергают конфиденциальной обработке, чтобы предотвратить раскрытие соответствующей идентификационной информации инициатора запроса и контроллера доступа при аутентификации во время осуществления передачи.

[0096] Следует отметить, что если сервер аутентификации, которому доверяет инициатор запроса, и сервер аутентификации, которому доверяет контроллер доступа при аутентификации, представляют собой один и тот же сервер аутентификации, т.е. инициатор запроса и контроллер доступа при аутентификации обычно доверяют одному и тому же серверу аутентификации, в этом случае сервер аутентификации, которому обычно доверяют инициатор запроса и контроллер доступа при аутентификации, может быть представлен сервером аутентификации, которому доверяет контроллер доступа при аутентификации (или, конечно, сервером аутентификации, которому доверяет инициатор запроса). В этом случае сервер аутентификации, которому доверяет контроллер доступа при аутентификации (который также может быть представлен как сервер аутентификации, которому доверяет инициатор запроса) может отправить EncPub_{AS_REQ} и EncPub_{AS_AAC} на сервер сертификатов для расшифровки, осуществляющий взаимодействие и имеющий доверительные отношения с сервером аутентификации, которому доверяет контроллер доступа при аутентификации, для расшифровки, и получить Cert_REQ, первое одноразовое случайное защитное число, Cert_AAC и второе одноразовое случайное защитное число, полученные путем расшифровки. Альтернативно сервер сертификатов для расшифровки может находиться в сервере аутентификации, которому доверяет контроллер доступа при аутентификации (который также может быть представлен как сервер аутентификации, которому доверяет инициатор запроса), и сервер аутентификации, которому доверяет контроллер доступа при аутентификации (который также может быть представлен как сервер аутентификации, которому доверяет инициатор запроса), использует закрытый ключ, соответствующий сертификату шифрования сервера сертификатов для расшифровки, чтобы соответственно расшифровать EncPub_{AS_REQ} и EncPub_{AS_AAC} для получения Cert_REQ, первого одноразового случайного защитного числа, Cert_AAC и второго одноразового случайного защитного числа. Сервер аутентификации, которому доверяет контроллер доступа при аутентификации (который также может быть представлен как сервер аутентификации, которому доверяет инициатор запроса), верифицирует легитимность Cert_AAC, чтобы получить первый результат верификации, верифицирует легитимность Cert_REQ, чтобы получить второй результат верификации, генерирует первую информацию о результате аутентификации в соответствии с информацией, включающей в себя первый результат верификации, генерирует вторую информацию о результате аутентификации в соответствии с информацией, включающей в себя второй результат верификации, шифрует информацию, включающую в себя первую информацию о результате аутентификации, путем использования второго одноразового случайного защитного числа, чтобы сгенерировать зашифрованный текст первой информации о результате аутентификации, шифрует информацию, включающую в себя вторую информацию о результате аутентификации, путем использования первого одноразового случайного защитного числа, чтобы сгенерировать зашифрованный текст второй информации о результате аутентификации, выполняет вычисление по подлежащим подписанию данным, включающим в себя зашифрованный текст первой информации о результате аутентификации, чтобы сгенерировать первую цифровую подпись Sig_{AS_AAC1} (которая также может быть представлена как Sig_{AS_REQ1}), выполняет вычисление по подлежащим подписанию данным, включающим в себя зашифрованный текст второй информации о результате аутентификации, чтобы сгенерировать вторую цифровую подпись Sig_{AS_AAC2} (которая также может быть представлена как Sig_{AS_REQ2}) и генерирует первое ответное сообщение ASVeri об аутентификации в соответствии с информацией, включающей в себя зашифрованный текст первой информации о результате аутентификации, Sig_{AS_AAC1} (которая также может быть представлена как Sig_{AS_REQ1}), зашифрованный текст второй информации о результате аутентификации и Sig_{AS_AAC2} (которая также может быть представлена как Sig_{AS_REQ2}).

[0097] Если сервер аутентификации, которому доверяет инициатор запроса, и сервер аутентификации, которому доверяет контроллер доступа при аутентификации, являются двумя разными серверами аутентификации, сервер аутентификации, которому доверяет контроллер доступа при аутентификации, может отправить EncPub_{AS_AAC} на сервер сертификатов для расшифровки, осуществляющий взаимодействие и имеющий доверительные отношения с сервером аутентификации, которому доверяет контроллер доступа при аутентификации, для расшифровки, и получить Cert_AAC и второе одноразовое случайное защитное число, полученные путем расшифровки. Альтернативно сервер аутентификации, которому доверяет контроллер доступа при аутентификации, сначала получает Cert_AAC и второе одноразовое случайное защитное число путем использования закрытого ключа, соответствующего сертификату шифрования сервера сертификатов для расшифровки, находящегося в сервере аутентификации, которому доверяет контроллер доступа при аутентификации, для расшифровки EncPub_{AS_AAC}. Сервер аутентификации, которому доверяет контроллер доступа при аутентификации, верифицирует легитимность Cert_AAC, чтобы получить первый результат верификации, генерирует первую информацию о результате аутентификации в соответствии с информацией, включающей в себя первый результат верификации, и шифрует информацию, включающую в себя первую информацию о результате аутентификации, путем использования второго одноразового случайного защитного числа, чтобы сгенерировать зашифрованный текст первой информации о результате аутентификации. Затем сервер аутентификации, которому доверяет контроллер доступа при аутентификации, отправляет сигнал AS-AACVeri на сервер аутентификации, которому доверяет инициатор запроса. Сигнал AS-AACVeri включает в себя зашифрованный текст первой информации о результате аутентификации, EncPub_{AS_REQ} и Sig_{AS_AAC3}. Sig_{AS_AAC3} генерируют путем выполнения сервером аутентификации, которому доверяет контроллер доступа при аутентификации, вычисления по подлежащим подписанию данным, включающим в себя зашифрованный текст первой информации о результате аутентификации и EncPub_{AS_REQ}. После приема AS-AACVeri сервер аутентификации, которому доверяет инициатор запроса, верифицирует Sig_{AS_AAC3} путем использования открытого ключа сервера аутентификации, которому доверяет контроллер доступа при аутентификации. После успешной верификации сервер аутентификации, которому доверяет инициатор запроса, может отправить EncPub_{AS_REQ} на сервер сертификатов для расшифровки, осуществляющий взаимодействие и имеющий доверительные отношения с сервером аутентификации, которому доверяет инициатор запроса, для расшифровки, и получить Cert_REQ и первое одноразовое случайное защитное число, полученные путем расшифровки. Альтернативно сервер аутентификации, которому доверяет инициатор запроса, сначала получает Cert_REQ и первое одноразовое случайное защитное число путем использования закрытого ключа, соответствующего сертификату шифрования сервера сертификатов для расшифровки, находящегося в сервере аутентификации, которому доверяет инициатор запроса, для расшифровки EncPub_{AS_REQ}. Сервер аутентификации, которому доверяет инициатор запроса, верифицирует легитимность Cert_REQ, чтобы получить второй результат верификации, генерирует вторую информацию о результате аутентификации в соответствии с информацией, включающей в себя второй результат верификации, шифрует информацию, включающую в себя вторую информацию о результате аутентификации, путем использования первого одноразового случайного защитного числа, чтобы сгенерировать зашифрованный текст второй информации о результате аутентификации, выполняет вычисление по подлежащим подписанию данным, включающим в себя зашифрованный текст второй информации о результате аутентификации, чтобы сгенерировать Sig_{AS_REQ4}, и выполняет вычисление по подлежащим подписанию данным, включающим в себя зашифрованный текст первой информации о результате аутентификации, чтобы сгенерировать Sig_{AS_REQ1}. Сервер аутентификации, которому доверяет инициатор запроса, отправляет второе ответное сообщение AS-REQVeri об аутентификации на сервер аутентификации, которому доверяет контроллер доступа при аутентификации. Сообщение AS-REQVeri включает в себя зашифрованный текст первой информации о результате аутентификации, Sig_{AS_REQ1}, зашифрованный текст второй информации о результате аутентификации и Sig_{AS_REQ4}. Сервер аутентификации, которому доверяет контроллер доступа при аутентификации, верифицирует Sig_{AS_REQ4} путем использования открытого ключа сервера аутентификации, которому доверяет инициатор запроса, после успешной верификации выполняет вычисление по подлежащим подписанию данным, включающим в себя зашифрованный текст второй информации о результате аутентификации, чтобы сгенерировать Sig_{AS_AAC2}, и генерирует ASVeri в соответствии с информацией, включающей в себя зашифрованный текст первой информации о результате аутентификации, Sig_{AS_REQ1}, зашифрованный текст второй информации о результате аутентификации и Sig_{AS_AAC2}.

[0098] На этапе S103 контроллер доступа при аутентификации принимает первое ответное сообщение ASVeri об аутентификации, отправленное сервером аутентификации, которому доверяет контроллер доступа при аутентификации.

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

[00100] На этапе S104 контроллер доступа при аутентификации верифицирует вторую цифровую подпись путем использования открытого ключа сервера аутентификации, которому доверяет контроллер доступа при аутентификации.

[00101] Если верификация успешна, выполняются последующие операции.

[00102] На этапе S105 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, отправляет третье ответное сообщение AACAuth об аутентификации на инициатор запроса.

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

[00104] На этапе S106 инициатор запроса расшифровывает EncData_AAC путем использования ключа шифрования сообщения, чтобы получить зашифрованный текст первой информации о результате аутентификации, первую цифровую подпись и второе одноразовое случайное защитное число.

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

[00106] На этапе S107 инициатор запроса верифицирует первую цифровую подпись путем использования открытого ключа сервера аутентификации, которому доверяет инициатор запроса.

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

[00108] На этапе S109 инициатор запроса отправляет четвертое ответное сообщение REQAuth об аутентификации на контроллер доступа при аутентификации.

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

[00110] Следует отметить, что порядок выполнения этапов S107-S109 не влияет на реализацию настоящего раскрытия и при практическом применении порядок выполнения S107-S109 может быть установлен в соответствии с требованиями. Предпочтительно рекомендуется, чтобы этап S107 выполнялся первым, и когда инициатор запроса не может верифицировать первую цифровую подпись, AACAuth отбрасывается; когда инициатором запроса верифицирована первая цифровая подпись, то выполняется этап S108; когда инициатор запроса определяет, что контроллер доступа при аутентификации легитимен, то выполняется этап S109; и когда инициатор запроса определяет, что контроллер доступа при аутентификации нелегитимен, инициатор запроса выбирает, в соответствии с локальной политикой, следует ли выполнять этап S109. С точки зрения эффективности предпочтительно не выполнять и не завершать этот процесс аутентификации.

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

[00112] На этапе S111 контроллер доступа при аутентификации определяет результат аутентификации идентификационной информации инициатора запроса в соответствии со вторым результатом верификации во второй информации о результате аутентификации.

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

[00114] В некоторых вариантах осуществления REQInit на этапе S101 может дополнительно включать в себя цифровую подпись Sig_REQ инициатора запроса; и подлежащие подписанию данные Sig_REQ включают в себя другие поля перед Sig_REQ в REQInit. Перед этапом S111 контроллер доступа при аутентификации дополнительно должен определить, успешна ли верификация Sig_REQ, и этап S111 может быть выполнен только при успешной верификации. Следует отметить, что если сервер аутентификации, которому доверяет инициатор запроса, и сервер аутентификации, которому доверяет контроллер доступа при аутентификации, представляют собой один и тот же сервер аутентификации, Sig_REQ может быть верифицирован сервером аутентификации, которому доверяет контроллер доступа при аутентификации (который также может быть представлен как сервер аутентификации, которому доверяет инициатор запроса), или может быть верифицирован контроллером доступа при аутентификации; и если сервер аутентификации, которому доверяет инициатор запроса, и сервер аутентификации, которому доверяет контроллер доступа при аутентификации, являются двумя разными серверами аутентификации, Sig_REQ может быть верифицирован сервером аутентификации, которому доверяет инициатор запроса, или может быть верифицирован контроллером доступа при аутентификации. Контроллер доступа при аутентификации определяет, с помощью нижеследующих способов, успешна ли верификация Sig_REQ.

[00115] В качестве варианта осуществления верификации Sig_REQ с помощью инициатора запроса, если сервер аутентификации, которому доверяет инициатор запроса, и сервер аутентификации, которому доверяет контроллер доступа при аутентификации, представляют собой один и тот же сервер аутентификации (не в роуминге), когда сервер аутентификации, которому доверяет контроллер доступа при аутентификации (который также может быть представлен как сервер аутентификации, которому доверяет инициатор запроса), верифицирует Sig_REQ, Sig_REQ может быть передан на сервер аутентификации, которому доверяет контроллер доступа при аутентификации (который также может быть представлен как сервер аутентификации, которому доверяет инициатор запроса) путем передачи в сигнале AACVeri на этапе S102, и сервер аутентификации, которому доверяет контроллер доступа при аутентификации (который также может быть представлен как сервер аутентификации, которому доверяет инициатор запроса), верифицирует Sig_REQ путем использования Cert_REQ, полученного путем расшифровки EncPub_{AS_REQ}; если верификация успешна, продолжается выполнение последующих операций для выполнения этапов генерации и отправки первого ответного сообщения об аутентификации; а если верификация не была успешной, последующие операции не выполняются и, таким образом, не выполняются этапы генерации и отправки первого ответного сообщения аутентификации. Следовательно, контроллер доступа при аутентификации выполнен с возможностью определения, в зависимости от того, может ли быть принято первое ответное сообщение об аутентификации, успешна ли верификация Sig_REQ. Если контроллер доступа при аутентификации может принять первое ответное сообщение об аутентификации, контроллер доступа при аутентификации может определить, что верификация Sig_REQ успешна.

[00116] В качестве еще одного варианта осуществления верификации Sig_REQ с помощью сервера аутентификации, если сервер аутентификации, которому доверяет инициатор запроса, и сервер аутентификации, которому доверяет контроллер доступа при аутентификации, являются двумя разными серверами аутентификации (роуминг), когда сервер аутентификации, которому доверяет инициатор запроса, верифицирует Sig_REQ, Sig_REQ может быть передан на сервер аутентификации, которому доверяет инициатор запроса, путем передачи в сигнале AACVeri на этапе S102 и AS-AACVeri будет отправлен на сервер аутентификации, которому доверяет инициатор запроса, посредством сервера аутентификации, которому доверяет контроллер доступа при аутентификации, и сервер аутентификации, которому доверяет инициатор запроса, верифицирует Sig_REQ путем использования Cert_REQ, полученного путем расшифровки EncPub_{AS_REQ}; если верификация успешна, продолжается выполнение последующих операций для выполнения этапов генерации и отправки второго ответного сообщения об аутентификации и последующего первого ответного сообщения об аутентификации; а если верификация не была успешной, последующие операции не выполняются и, таким образом, не выполняются этапы генерации и отправки второго ответного сообщения об аутентификации и последующего первого ответного сообщения об аутентификации. Следовательно, контроллер доступа при аутентификации выполнен с возможностью определения, в зависимости от того, может ли быть принято первое ответное сообщение об аутентификации, успешна ли верификация Sig_REQ. Если контроллер доступа при аутентификации может принять первое ответное сообщение об аутентификации, контроллер доступа при аутентификации может определить, что верификация Sig_REQ успешна.

[00117] В качестве варианта осуществления верификации Sig_REQ с помощью контроллера доступа при аутентификации, когда контроллер доступа при аутентификации верифицирует Sig_REQ, вторая информация о результате аутентификации, сгенерированная сервером аутентификации, дополнительно включает в себя Cert_REQ. После приема REQAuth на этапе S109 контроллер доступа при аутентификации может верифицировать Sig_REQ путем использования Cert_REQ во второй информации о результате аутентификации, которую получают путем расшифровки зашифрованного текста второй информации о результате аутентификации, чтобы определить, успешна ли верификация Sig_REQ.

[00118] В некоторых других вариантах осуществления REQAuth на этапе S109 может дополнительно включать в себя Sig_REQ инициатора запроса; и подлежащие подписанию данные Sig_REQ включают в себя другие поля перед Sig_REQ в REQAuth. В этом случае вторая информация о результате аутентификации, сгенерированная сервером аутентификации, дополнительно включает в себя Cert_REQ. Перед этапом S111 контроллер доступа при аутентификации дополнительно должен верифицировать Sig_REQ путем использования Cert_REQ во второй информации о результате аутентификации и определить, успешна ли верификация Sig_REQ; и этап S111 может быть выполнен только при успешной верификации.

[00119] В некоторых вариантах осуществления AACVeri на этапе S102 может дополнительно включать в себя цифровую подпись Sig_AAC контроллера доступа при аутентификации; и подлежащие подписанию данные Sig_AAC включают в себя другие поля перед Sig_AAC в AACVeri. Перед этапом S108 инициатор запроса дополнительно должен определить, успешна ли верификация Sig_AAC, и этап S108 может быть выполнен только при успешной верификации. Инициатор запроса определяет, с помощью нижеследующих способов, успешна ли верификация Sig_AAC. Сервер аутентификации, которому доверяет контроллер доступа при аутентификации, верифицирует Sig_AAC путем использования Cert_AAC, полученного путем расшифровки EncPub_{AS_AAC} в AACVeri, и последующие процессы выполняются после успешной верификации таким образом, что если инициатор запроса может принять AACAuth на этапе S105, инициатор запроса определяет, что верификация Sig_AAC успешна.

[00120] В некоторых других вариантах осуществления AACAuth на этапе S105 может дополнительно включать в себя Sig_AAC контроллера доступа при аутентификации; и подлежащие подписанию данные Sig_AAC включают в себя другие поля перед Sig_AAC в AACAuth. Соответственно, первая информация о результате аутентификации, сгенерированная сервером аутентификации, дополнительно включает в себя Cert_AAC. Перед тем, как инициатор запроса определит результат аутентификации идентификационной информации контроллера доступа при аутентификации на этапе S108, инициатор запроса также должен определить, успешна ли верификация Sig_AAC, и результат аутентификации идентификационной информации контроллера доступа при аутентификации может быть определен только в соответствии с первым результатом верификации, когда верификация успешна. Инициатор запроса определяет, с помощью нижеследующих способов, успешна ли верификация Sig_AAC. Инициатор запроса верифицирует Sig_AAC путем использования Cert_AAC в первой информации о результате аутентификации, которую получают путем расшифровки зашифрованного текста первой информации о результате аутентификации, и определяет, успешна ли верификация Sig_AAC, в соответствии с результатом верификации.

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

[00122] Например, в REQInit на этапе S101 подлежащие шифрованию данные EncPub_{AS_REQ} могут дополнительно включать в себя ID_REQ инициатора запроса и третье одноразовое случайное защитное число Nonce_REQID; и Nonce_REQID используют для шифрования ID_REQ. Соответственно, ASVeri на этапе S103 может дополнительно включать в себя зашифрованный текст идентификационного идентификатора инициатора запроса. Например, зашифрованный текст идентификационного идентификатора инициатора запроса может представлять собой текст: «ID_REQ⊕Nonce_REQID», который является результатом операции «исключающего или» (exclusive or operation, XOR) ID_REQ и Nonce_REQID. В AACAuth на этапе S105 подлежащие шифрованию данные EncData_AAC дополнительно включают в себя зашифрованный текст идентификационного идентификатора инициатора запроса. Инициатор запроса также получает зашифрованный текст идентификационного идентификатора инициатора запроса путем расшифровки EncData_AAC. Инициатор запроса также должен верифицировать, в соответствии с собственным ID_REQ и Nonce_REQID, зашифрованный текст идентификационного идентификатора инициатора запроса, полученный путем расшифровки EncData_AAC. Например, верификация может включать следующее. Инициатор запроса шифрует информацию, включающую в себя собственный ID_REQ инициатора запроса, путем использования Nonce_REQID, чтобы сгенерировать зашифрованный текст идентификационного идентификатора инициатора запроса и выполнить верификацию непротиворечивости по сгенерированному зашифрованному тексту идентификационного идентификатора инициатора запроса и зашифрованному тексту идентификационного идентификатора инициатора запроса, который получен путем расшифровки EncData_AAC. Альтернативно инициатор запроса расшифровывает зашифрованный текст идентификационного идентификатора инициатора запроса путем использования Nonce_REQID, чтобы получить ID_REQ, и выполняет верификацию непротиворечивости его и собственного ID_REQ инициатора запроса; и если верификация успешна, инициатор запроса затем выполняет этап определения результата аутентификации идентификационной информации контроллера доступа при аутентификации на этапе S108.

[00123] Аналогично в AACVeri на этапе S102 подлежащие шифрованию данные EncPub_{AS_AAC} могут дополнительно включать в себя ID_AAC контроллера доступа при аутентификации и четвертое одноразовое случайное защитное число Nonce_AACID, и Nonce_AACID используют для шифрования ID_AAC. Соответственно, ASVeri на этапе S103 может дополнительно включать в себя зашифрованный текст идентификационного идентификатора контроллера доступа при аутентификации. Например, зашифрованный текст идентификационного идентификатора контроллера доступа при аутентификации может представлять собой текст: «ID_AAC⊕Nonce_AACID», который является результатом операции «исключающего или» ID_AAC и Nonce_AACID. Прежде чем определить результат аутентификации идентификационной информации инициатора запроса, контроллер доступа при аутентификации должен дополнительно верифицировать зашифрованный текст идентификационного идентификатора контроллера доступа при аутентификации в соответствии с собственным ID_AAC и Nonce_AACID. Например, верификация включает следующее. Контроллер доступа при аутентификации шифрует информацию, включающую в себя собственный ID_AAC контроллера доступа при аутентификации путем использования Nonce_AACID, чтобы сгенерировать зашифрованный текст идентификационного идентификатора контроллера доступа при аутентификации, и выполняет верификацию непротиворечивости сгенерированного зашифрованного текста идентификационного идентификатора контроллера доступа при аутентификации и принятого зашифрованного текста идентификационного идентификатора контроллера доступа при аутентификации в ASVeri на этапе S103; или контроллер доступа при аутентификации может расшифровать зашифрованный текст идентификационного идентификатора контроллера доступа при аутентификации путем использования Nonce_AACID, чтобы получить ID_AAC, и выполняет верификацию непротиворечивости его и собственного ID_AAC контроллера доступа при аутентификации. Контроллер доступа при аутентификации затем выполняет этап определения результата аутентификации идентификационной информации инициатора запроса на этапе S111, если верификация успешна.

[00124] В некоторых вариантах осуществления, если REQInit на этапе S101 дополнительно включает в себя Nonce_REQ, сгенерированный инициатором запроса, то AACVeri на этапе S102 дополнительно включает в себя Nonce_AAC, сгенерированный контроллером доступа при аутентификации, и Nonce_REQ. Соответственно, ASVeri на этапе S103 может дополнительно включать в себя Nonce_REQ и Nonce_AAC; и в AACAuth на этапе S105 подлежащие шифрованию данные EncData_AAC дополнительно включают в себя Nonce_REQ. После приема ASVeri на этапе S103 контроллер доступа при аутентификации должен дополнительно верифицировать непротиворечивость между Nonce_AAC в ASVeri и Nonce_AAC (который представляет собой Nonce_AAC, отправленный контроллером доступа при аутентификации через AACVeri), сгенерированным контроллером доступа при аутентификации; и если верификация успешна, контроллер доступа при аутентификации затем выполняет этап определения результата аутентификации идентификационной информации инициатора запроса на этапе S111. После приема AACAuth на этапе S105 инициатор запроса также должен верифицировать непротиворечивость между Nonce_REQ, полученным путем расшифровки EncData_AAC, и Nonce_REQ (который является Nonce_REQ, отправленным инициатором запроса через REQInit), сгенерированным инициатором запроса; и если верификация успешна, инициатор запроса затем выполняет этап определения результата аутентификации идентификационной информации контроллера доступа при аутентификации на этапе S108.

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

[00126] Аналогичным образом, инициатор запроса также может сгенерировать код проверки целостности сообщения. Например, REQAuth на этапе S109 может дополнительно включать в себя второй код MacTag_REQ проверки целостности сообщения. MacTag_REQ генерируется инициатором запроса путем использования ключа проверки целостности сообщения для выполнения вычисления по полям в REQAuth, отличным от MacTag_REQ. Контроллер доступа при аутентификации также должен верифицировать MacTag_REQ; и после успешной верификации затем выполняется этап определения результата аутентификации идентификационной информации инициатора запроса на этапе S111. При верификации MacTag_REQ контроллер доступа при аутентификации должен использовать ключ проверки целостности сообщения для выполнения вычисления по полям в REQAuth, отличным от MacTag_REQ, чтобы сгенерировать MacTag_REQ и сравнить вычисленный MacTag_REQ с принятым MacTag_REQ в REQAuth; если эти MacTag_REQ непротиворечивы, верификация успешна; а если эти MacTag_AAC противоречивы, верификация не была успешной. Способ генерации ключа проверки целостности сообщения, используемого инициатором запроса и контроллером доступа при аутентификации, описан в нижеследующем варианте осуществления.

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

[00128] На этапе S201 контроллер доступа при аутентификации отправляет AACInit на инициатор запроса.

[00129] AACInit включает в себя параметр KeyInfo_AAC обмена ключами контроллера доступа при аутентификации, а KeyInfo_AAC включает в себя временный открытый ключ контроллера доступа при аутентификации. Обмен ключами относится к алгоритму обмена ключами, такому как алгоритм Диффи-Хеллмана (Diffie-Hellman, DH). AACInit может дополнительно включать в себя Nonce_AAC, сгенерированное контроллером доступа при аутентификации.

[00130] AACInit может дополнительно включать в себя средства безопасности_AAC; и средства безопасности_AAC представляют информацию о параметре средства безопасности, поддерживаемом контроллером доступа при аутентификации, включающую в себя пакет аутентификации идентификационной информации (который включает в себя один или более способов аутентификации идентификационной информации), поддерживаемый контроллером доступа при аутентификации, один или более алгоритмов симметричного шифрования, один или более алгоритмов проверки целостности и/или один или более алгоритмов формирования ключа, чтобы обеспечить возможность для инициатора запроса выбрать конкретную политику безопасности для использования. Следовательно, инициатор запроса может выбрать, в соответствии со средствами безопасности_AAC, конкретную политику безопасности (средства безопасности_REQ), используемую инициатором запроса. Средства безопасности_REQ указывают способ аутентификации идентификационной информации, алгоритм симметричного шифрования, алгоритм проверки целостности и/или алгоритм формирования ключа, которые, соответственно, определены для использования инициатором запроса.

[00131] На этапе S202 инициатор запроса выполняет вычисление обмена ключами в соответствии с временным закрытым ключом, соответствующим параметру KeyInfo_REQ обмена ключами инициатора запроса и временным открытым ключом, включенным в KeyInfo_AAC, чтобы сгенерировать первый ключ, и вычисляет ключ шифрования сообщения путем использования алгоритма формирования ключа в соответствии с информацией, включающей в себя первый ключ.

[00132] Если AACInit на этапе S201 дополнительно включает в себя Nonce_AAC, сгенерированное контроллером доступа при аутентификации, инициатор запроса может выполнить вычисление обмена ключами в соответствии с временным закрытым ключом, соответствующим KeyInfo_REQ, и временным открытым ключом, включенным в KeyInfo_AAC, чтобы сгенерировать первый ключ K1; причем K1 объединяют с информацией, включающей в себя Nonce_AAC и Nonce_REQ, сгенерированные инициатором запроса; и ключ шифрования сообщения вычисляют путем использования согласованного или заранее заданного алгоритма формирования ключа. Согласованный алгоритм формирования ключа может быть представлять собой алгоритм формирования ключа, который инициатор запроса выбирает для использования в соответствии с средствами безопасности_AAC, отправленными контроллером доступа при аутентификации. KeyInfo_REQ представляет собой параметр обмена ключами, сгенерированный инициатором запроса и включающий в себя временный открытый ключ инициатора запроса. Временный закрытый ключ, соответствующий KeyInfo_REQ, является временным закрытым ключом, который генерируется инициатором запроса, и соответствует временному открытому ключу инициатора запроса, т.е. временный открытый ключ и временный закрытый ключ представляют собой пару временного открытого и временного закрытого ключей.

[00133] На этапе S203 инициатор запроса отправляет REQInit на контроллер доступа при аутентификации.

[00134] REQInit включает в себя KeyInfo_REQ, так что контроллер доступа при аутентификации получает ключ шифрования сообщения путем выполнения вычисления в соответствии с информацией, включающей в себя временный закрытый ключ, соответствующий KeyInfo_AAC, и временный открытый ключ, включенный в KeyInfo_REQ. Временный закрытый ключ, соответствующий KeyInfo_AAC, является временным закрытым ключом, который генерирует контроллер доступа при аутентификации, и соответствует временному открытому ключу контроллера доступа при аутентификации, т.е. временный открытый ключ и временный закрытый ключ представляют собой пару временного открытого и временного закрытого ключей.

[00135] REQInit может дополнительно включать в себя средства безопасности_REQ. REQInit может дополнительно включать в себя Nonce_REQ, так что контроллер доступа при аутентификации получает ключ шифрования сообщения путем выполнения вычисления в соответствии с информацией, включающей в себя временный закрытый ключ, соответствующий KeyInfo_AAC, и временный открытый ключ, включенный в KeyInfo_REQ, Nonce_AAC и Nonce_REQ.

[00136] REQInit может дополнительно включать в себя Nonce_AAC, таким образом, перед вычислением ключа шифрования сообщения контроллер доступа при аутентификации может верифицировать непротиворечивость между Nonce_AAC в REQInit и Nonce_AAC, сгенерированным контроллером доступа при аутентификации, чтобы гарантировать, что REQInit, принятый контроллером доступа при аутентификации, является ответным сообщением для AACInit.

[00137] На этапе S204 контроллер доступа при аутентификации выполняет вычисление обмена ключами в соответствии с временным закрытым ключом, соответствующим KeyInfo_AAC, и временным открытым ключом, включенным в KeyInfo_REQ, чтобы сгенерировать первый ключ, и вычисляет ключ шифрования сообщения путем использования алгоритма формирования ключа в соответствии с информацией, включающей в себя первый ключ.

[00138] Если REQInit дополнительно включает в себя Nonce_REQ, контроллер доступа при аутентификации может выполнить вычисление обмена ключами в соответствии с временным закрытым ключом, соответствующим KeyInfo_AAC, и временным открытым ключом, включенным в KeyInfo_REQ, чтобы сгенерировать первый ключ K1; причем K1 объединяют с информацией, включающей в себя Nonce_AAC и Nonce_REQ; и ключ шифрования сообщения вычисляют с использованием согласованного или заранее заданного алгоритма формирования ключа. Согласованный алгоритм формирования ключа может представлять собой алгоритм формирования ключа, который контроллер доступа при аутентификации выбирает для использования в соответствии со средствами безопасности_REQ, отправленными инициатором запроса.

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

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

[00141] Со ссылкой на фиг. 2 контроллер доступа при аутентификации добавляет в AACInit на этапе S201 ID_{AS_AAC} по меньшей мере одного сервера аутентификации, которому доверяет контроллер доступа при аутентификации; а инициатор запроса определяет, в соответствии с ID_{AS_AAC}, ID_{AS_REQ} по меньшей мере одного сервера аутентификации, которому доверяет инициатор запроса. В ходе реализации инициатор запроса выбирает из ID_{AS_AAC} идентификационный идентификатор по меньшей мере одного сервера аутентификации, которому доверяет инициатор запроса, в качестве ID_{AS_REQ}; и если выбор не был успешным, инициатор запроса использует идентификационный идентификатор по меньшей мере одного сервера аутентификации, которому доверяет инициатор запроса, в качестве ID_{AS_REQ} (успешный выбор соответствует случаю отсутствия роуминга, а неудачный выбор соответствует случаю наличия роуминга), и ID_{AS_REQ} добавляют в REQInit на этапе S203 и отправляют контроллеру доступа при аутентификации. Следовательно, контроллер доступа при аутентификации выполнен с возможностью определения первого сервера аутентификации в соответствии с ID_{AS_AAC} и ID_{AS_REQ}. Например, контроллер доступа при аутентификации выполнен с возможностью определения того, имеется ли по меньшей мере один и тот же сервер аутентификации в ID_{AS_REQ} и ID_{AS_AAC}; если это так, т.е. в случае отсутствия роуминга, контроллер доступа при аутентификации определяет сервер аутентификации, которому доверяет контроллер доступа при аутентификации, участвующий в аутентификации идентификационной информации, по идентификационному идентификатору сервера аутентификации, которому обычно доверяют по меньшей мере один инициатор запроса и контроллер доступа при аутентификации; и если это не так, т.е. в случае наличия роуминга, контроллер доступа при аутентификации должен определить, в соответствии с ID_{AS_AAC}, сервер аутентификации, которому доверяет контроллер доступа при аутентификации, участвующий в аутентификации идентификационной информации, и отправляет ID_{AS_REQ} на сервер аутентификации, которому доверяет контроллер доступа при аутентификации, таким образом, сервер аутентификации, которому доверяет контроллер доступа при аутентификации, определяет сервер аутентификации, которому доверяет инициатор запроса, в соответствии с ID_{AS_REQ}.

[00142] В качестве еще одного варианта реализации контроллер доступа при аутентификации может не отправлять ID_{AS_AAC} на инициатор запроса, и инициатор запроса добавляет, в REQInit на этапе S203, ID_{AS_REQ} по меньшей мере одного сервера аутентификации, которому доверяет инициатор запроса. Определение сервера аутентификации, которому доверяет контроллер доступа при аутентификации, и/или сервера аутентификации, которому доверяет инициатор запроса, участвующих в процессе аутентификации идентификационной информации, в соответствии с ID_{AS_REQ} и ID_{AS_AAC} сервера аутентификации, которому доверяет контроллер доступа при аутентификации, реализуют так же, как и в предыдущем варианте реализации.

[00143] Для простоты описания в нижеследующих вариантах осуществления первый результат верификации, полученный путем верификации легитимности Cert_AAC, представлен как Res_AAC; первая информация о результате аутентификации представлена как Pub_AAC; второй результат верификации, полученный путем верификации легитимности Cert_REQ, представлен как Res_REQ; вторая информация о результате аутентификации представлена как Pub_REQ.

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

[00145] В случае отсутствия роуминга сервер аутентификации, которому доверяет контроллер доступа при аутентификации (или сервер аутентификации, которому доверяет инициатор запроса), может использоваться для представления сервера аутентификации, которому обычно доверяют инициатор запроса и контроллер доступа при аутентификации, а также может верифицировать Sig_REQ инициатора запроса и Sig_AAC контроллера доступа при аутентификации во время аутентификации идентификационной информации. Например, сервер аутентификации, которому доверяет контроллер доступа при аутентификации (или сервер аутентификации, которому доверяет инициатор запроса) может быть использован для верификации Sig_REQ и Sig_AAC; или контроллер доступа при аутентификации может быть использован для верификации Sig_REQ, а инициатор запроса верифицирует Sig_AAC.

[00146] На фиг. 3 представлен вариант осуществления способа аутентификации идентификационной информации контроллера доступа при аутентификации, верифицирующего Sig_REQ, и инициатора запроса, верифицирующего Sig_AAC, в случае отсутствия роуминга. Перед выполнением этого варианта осуществления и инициатор запроса, и контроллер доступа при аутентификации имеют ключ шифрования сообщения, и ключ шифрования сообщения может быть заранее совместно использован обеими сторонами или может быть получен путем согласования способом, показанным на фиг. 2. Этот способ аутентификации идентификационной информации включает следующие этапы. Этот способ аутентификации идентификационной информации включает следующие этапы.

[00147] На этапе S301 контроллер доступа при аутентификации получает сигнал REQInit, отправленный инициатором запроса.

[00148] REQInit включает в себя EncPub_{AS_REQ} инициатора запроса и Sig_REQ инициатора запроса.

[00149] На этапе S302 контроллер доступа при аутентификации отправляет AACVeri на сервер аутентификации, которому доверяет контроллер доступа при аутентификации.

[00150] Сигнал AACVeri включает в себя EncPub_{AS_REQ} и зашифрованный текст EncPub_{AS_AAC} идентификационной информации контроллера доступа при аутентификации.

[00151] На этапе S303 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, расшифровывает EncPub_{AS_REQ} и EncPub_{AS_AAC} путем использования закрытого ключа, соответствующего сертификату шифрования, чтобы получить Cert_REQ, Nonce_REQPub, Cert_AAC и Nonce_AACPub, соответственно, выполняет верификацию легитимности по Cert_AAC и Cert_REQ, чтобы получить Res_AAC и Res_REQ, генерирует Pub_AAC в соответствии с информацией, включающей в себя Cert_AAC и Res_AAC, генерирует Pub_REQ в соответствии с информацией, включающей в себя Cert_REQ и Res_REQ, шифрует информацию, включающую в себя Pub_AAC, путем использования Nonce_AACPub, чтобы сгенерировать зашифрованный текст первой информации о результате аутентификации, шифрует информацию, включающую в себя Pub_REQ, путем использования Nonce_REQPub, чтобы сгенерировать зашифрованный текст второй информации о результате аутентификации, генерирует Sig_{AS_AAC1} путем выполнения вычисления по подлежащим подписанию данным, включающим в себя зашифрованный текст первой информации о результате аутентификации, и генерирует Sig_{AS_AAC2} путем выполнения вычисления по подлежащим подписанию данным, включающим в себя зашифрованный текст второй информации о результате аутентификации.

[00152] На этапе S304 контроллер доступа при аутентификации принимает первое ответное сообщение ASVeri об аутентификации, отправленное сервером аутентификации, которому доверяет контроллер доступа при аутентификации.

[00153] Сообщение ASVeri включает в себя зашифрованный текст первой информации о результате аутентификации, Sig_{AS_AAC1}, зашифрованный текст второй информации о результате аутентификации и Sig_{AS_AAC2}.

[00154] На этапе S305 контроллер доступа при аутентификации верифицирует Sig_{AS_AAC2} путем использования открытого ключа сервера аутентификации, которому доверяет контроллер доступа при аутентификации, если верификация успешна, шифрует подлежащие шифрованию данные, включающие в себя зашифрованный текст первой информации о результате аутентификации, Sig_{AS_AAC1} и Nonce_AACPub путем использования ключа шифрования сообщения, чтобы сгенерировать EncData_AAC, и генерирует Sig_AAC путем выполнения вычисления по подлежащим подписанию данным, включающим в себя EncData_AAC.

[00155] На этапе S306 контроллер доступа при аутентификации отправляет третье ответное сообщение AACAuth об аутентификации на инициатор запроса.

[00156] AACAuth включает в себя EncData_AAC и Sig_AAC.

[00157] На этапе S307 инициатор запроса расшифровывает EncData_AAC путем использования ключа шифрования сообщения, чтобы получить зашифрованный текст первой информации о результате аутентификации, Sig_{AS_AAC1} и Nonce_AACPub.

[00158] На этапе S308 инициатор запроса расшифровывает зашифрованный текст первой информации о результате аутентификации путем использования Nonce_AACPub, чтобы получить Pub_AAC.

[00159] На этапе S309 инициатор запроса верифицирует Sig_AAC путем использования Cert_AAC в Pub_AAC и верифицирует Sig_{AS_AAC1} путем использования открытого ключа сервера аутентификации, которому доверяет контроллер доступа при аутентификации.

[00160] Если все верификации успешны, затем выполняется этап S310.

[00161] На этапе S310 инициатор запроса определяет результат аутентификации идентификационной информации контроллера доступа при аутентификации в соответствии с Res_AAC в Pub_AAC.

[00162] Когда инициатор запроса определяет, что контроллер доступа при аутентификации легитимен, то выполняется этап S311; и когда инициатор запроса определяет, что контроллер доступа при аутентификации нелегитимен, текущий процесс аутентификации завершается.

[00163] На этапе S311 инициатор запроса шифрует информацию, включающую в себя Nonce_REQPub, путем использования ключа шифрования сообщения, чтобы получить EncData_REQ.

[00164] На этапе S312 инициатор запроса отправляет четвертое ответное сообщение REQAuth об аутентификации на контроллер доступа при аутентификации.

[00165] REQAuth включает в себя EncData_REQ.

[00166] На этапе S313 контроллер доступа при аутентификации расшифровывает EncData_REQ путем использования ключа шифрования сообщения, чтобы получить Nonce_REQPub, и расшифровывает зашифрованный текст второй информации о результате аутентификации путем использования Nonce_REQPub, чтобы получить Pub_REQ.

[00167] На этапе S314 контроллер доступа при аутентификации верифицирует Sig_REQ путем использования Cert_REQ в Pub_REQ.

[00168] Если верификация успешна, выполняется этап S315.

[00169] На этапе S315 контроллер доступа при аутентификации определяет результат аутентификации идентификационной информации инициатора запроса в соответствии с Res_REQ в Pub_REQ.

[00170] Следует отметить, что REQInit на этапе S301 может не включать в себя Sig_REQ, но при этом Sig_REQ добавлен в REQAuth на этапе S312. Другими словами, на этапе S312 инициатор запроса сначала генерирует Sig_REQ путем выполнения вычисления по подлежащим подписанию данным, включающим в себя EncData_REQ в REQAuth. В этом случае Sig_REQ, верифицированная контроллером доступа при аутентификации на этапе S314, представляет собой Sig_REQ в REQAuth на этапе S312.

[00171] На фиг. 4 представлен еще один вариант осуществления способа аутентификации идентификационной информации сервера аутентификации, которому доверяет контроллер доступа при аутентификации, верифицирующего Sig_REQ и Sig_AAC в случае отсутствия роуминга. Перед выполнением этого варианта осуществления и инициатор запроса, и контроллер доступа при аутентификации имеют ключ шифрования сообщения, и ключ шифрования сообщения может быть заранее совместно использован обеими сторонами или может быть получен путем согласования способом, показанным на фиг. 2. Этот способ аутентификации идентификационной информации включает следующие этапы. Этот способ аутентификации идентификационной информации включает следующие этапы.

[00172] На этапе S401 контроллер доступа при аутентификации получает сигнал REQInit, отправленный инициатором запроса.

[00173] REQInit включает в себя EncPub_{AS_REQ} инициатора запроса и Sig_REQ инициатора запроса.

[00174] На этапе S402 контроллер доступа при аутентификации отправляет AACVeri на сервер аутентификации, которому доверяет контроллер доступа при аутентификации.

[00175] AACVeri включает в себя REQInit, EncPub_{AS_AAC} контроллера доступа при аутентификации и Sig_AAC контроллера доступа при аутентификации. Sig_AAC генерируют путем выполнения вычислений в других полях перед Sig_AAC в AACVeri.

[00176] На этапе S403 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, расшифровывает EncPub_{AS_REQ} и EncPub_{AS_AAC} путем использования закрытого ключа, соответствующего сертификату шифрования, чтобы получить Cert_REQ, Nonce_REQPub, Cert_AAC и Nonce_AACPub, верифицирует Sig_REQ путем использования Cert_REQ, и верифицирует Sig_AAC путем использования Cert_AAC.

[00177] Если все верификации успешны, выполняется этап S404.

[00178] На этапе S404 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, выполняет верификацию легитимности Cert_AAC и Cert_REQ, чтобы получить Res_AAC и Res_REQ, генерирует Pub_AAC в соответствии с информацией, включающей в себя Res_AAC, генерирует Pub_REQ в соответствии с информацией, включающей в себя Res_REQ, шифрует информацию, включающую в себя Pub_AAC, путем использования Nonce_AACPub, чтобы сгенерировать зашифрованный текст первой информации о результате аутентификации, шифрует информацию, включающую в себя Pub_REQ, путем использования Nonce_REQPub, чтобы сгенерировать зашифрованный текст второй информации о результате аутентификации, генерирует Sig_{AS_AAC1} путем выполнения вычисления по подлежащим подписанию данным, включающим в себя зашифрованный текст первой информации о результате аутентификации, и генерирует Sig_{AS_AAC2} путем выполнения вычисления по подлежащим подписанию данным, включающим в себя зашифрованный текст второй информации о результате аутентификации.

[00179] На этапе S405 контроллер доступа при аутентификации принимает первое ответное сообщение ASVeri об аутентификации, отправленное сервером аутентификации, которому доверяет контроллер доступа при аутентификации.

[00180] Сообщение ASVeri включает в себя зашифрованный текст первой информации о результате аутентификации, Sig_{AS_AAC1}, зашифрованный текст второй информации о результате аутентификации и Sig_{AS_AAC2}.

[00181] На этапе S406 контроллер доступа при аутентификации верифицирует Sig_{AS_AAC2} путем использования открытого ключа сервера аутентификации, которому доверяет контроллер доступа при аутентификации, если верификация успешна, шифрует подлежащие шифрованию данные, включающие в себя зашифрованный текст первой информации о результате аутентификации, Sig_{AS_AAC1} и Nonce_AACPub путем использования ключа шифрования сообщения, чтобы сгенерировать EncData_AAC.

[00182] На этапе S407 контроллер доступа при аутентификации отправляет третье ответное сообщение AACAuth об аутентификации на инициатор запроса.

[00183] AACAuth включает в себя EncData_AAC.

[00184] На этапе S408 инициатор запроса расшифровывает EncData_AAC путем использования ключа шифрования сообщения, чтобы получить зашифрованный текст первой информации о результате аутентификации, Sig_{AS_AAC1} и Nonce_AACPub.

[00185] На этапе S409 инициатор запроса верифицирует Sig_{AS_AAC1} путем использования открытого ключа сервера аутентификации, которому доверяет контроллер доступа при аутентификации.

[00186] Если верификация успешна, выполняется этап S410.

[00187] На этапе S410 инициатор запроса расшифровывает зашифрованный текст первой информации о результате аутентификации путем использования Nonce_AACPub, чтобы получить Pub_AAC.

[00188] На этапе S411 инициатор запроса определяет результат аутентификации идентификационной информации контроллера доступа при аутентификации в соответствии с Res_AAC в Pub_AAC.

[00189] Когда инициатор запроса определяет, что контроллер доступа при аутентификации легитимен, то выполняется этап S412; и когда инициатор запроса определяет, что контроллер доступа при аутентификации нелегитимен, текущий процесс аутентификации завершается.

[00190] На этапе S412 инициатор запроса шифрует информацию, включающую в себя Nonce_REQPub, путем использования ключа шифрования сообщения, чтобы получить EncData_REQ.

[00191] На этапе S413 инициатор запроса отправляет четвертое ответное сообщение REQAuth об аутентификации на контроллер доступа при аутентификации.

[00192] REQAuth включает в себя EncData_REQ.

[00193] На этапе S414 контроллер доступа при аутентификации расшифровывает EncData_REQ с использованием ключа шифрования сообщения, чтобы получить Nonce_REQPub, и расшифровывает зашифрованный текст второй информации о результате аутентификации путем использования Nonce_REQPub, чтобы получить Pub_REQ.

[00194] На этапе S415 контроллер доступа при аутентификации определяет результат аутентификации идентификационной информации инициатора запроса в соответствии с Res_REQ в Pub_REQ.

[00195] В случае наличия роуминга сервер аутентификации, которому доверяет контроллер доступа при аутентификации, и сервер аутентификации, которому доверяет инициатор запроса, доверяют друг другу и им известны цифровые сертификаты друг друга или открытый ключ в цифровом сертификате. Sig_REQ инициатора запроса и Sig_AAC контроллера доступа при аутентификации также могут быть верифицированы во время аутентификации идентификационной информации. Например, сервер аутентификации, которому доверяет инициатор запроса, может быть использован для верификации Sig_REQ, и сервер аутентификации, которому доверяет контроллер доступа при аутентификации, используют для верификации Sig_AAC; или контроллер доступа при аутентификации может быть использован для верификации Sig_REQ, а инициатор запроса верифицирует Sig_AAC.

[00196] На фиг. 5 представлен вариант осуществления способа аутентификации идентификационной информации контроллера доступа при аутентификации, верифицирующего Sig_REQ, и инициатора запроса, верифицирующего Sig_AAC, в случае наличия роуминга. Перед выполнением этого варианта осуществления и инициатор запроса, и контроллер доступа при аутентификации имеют ключ шифрования сообщения, и ключ шифрования сообщения может быть заранее совместно использован обеими сторонами или может быть получен путем согласования способом, показанным на фиг. 2. Этот способ аутентификации идентификационной информации включает следующие этапы. Этот способ аутентификации идентификационной информации включает следующие этапы.

[00197] На этапе S501 контроллер доступа при аутентификации получает сигнал REQInit, отправленный инициатором запроса.

[00198] REQInit включает в себя EncPub_{AS_REQ} инициатора запроса, ID_{AS_REQ} по меньшей мере одного сервера аутентификации, которому доверяет инициатор запроса, и Sig_REQ инициатора запроса.

[00199] На этапе S502 контроллер доступа при аутентификации отправляет AACVeri на сервер аутентификации, которому доверяет контроллер доступа при аутентификации.

[00200] AACVeri включает в себя EncPub_{AS_REQ}, ID_{AS_REQ} и EncPub_{AS_AAC} контроллера доступа при аутентификации.

[00201] На этапе S503 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, расшифровывает EncPub_{AS_AAC}, чтобы получить Cert_AAC и Nonce_AACPub.

[00202] На этапе S504 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, выполняет верификацию легитимности Cert_AAC, чтобы получить Res_AAC, генерирует Pub_AAC в соответствии с информацией, включающей в себя Cert_AAC и Res_AAC, шифрует информацию, включающую в себя Pub_AAC, путем использования Nonce_AACPub, чтобы сгенерировать зашифрованный текст первой информации о результате аутентификации, и генерирует Sig_{AS_AAC3} путем выполнения вычисления по подлежащим подписанию данным, включающим в себя зашифрованный текст первой информации о результате аутентификации и EncPub_{AS_REQ}.

[00203] На этапе S505 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, отправляет сигнал AS-AACVeri на сервер аутентификации, которому доверяет инициатор запроса.

[00204] Сервер аутентификации, которому доверяет контроллер доступа при аутентификации, выполнен с возможностью определения, в соответствии с ID_{AS_REQ}, сервера аутентификации, которому доверяет инициатор запроса, используемого во время текущего процесса аутентификации, и отправить AS-AACVeri на сервер аутентификации, которому доверяет инициатор запроса. Сигнал AS-AACVeri включает в себя зашифрованный текст первой информации о результате аутентификации, EncPub_{AS_REQ} и Sig_{AS_AAC3}.

[00205] На этапе S506 сервер аутентификации, которому доверяет инициатор запроса, верифицирует Sig_{AS_AAC3} путем использования открытого ключа сервера аутентификации, которому доверяет контроллер доступа при аутентификации.

[00206] Если верификация успешна, выполняется этап S507.

[00207] На этапе S507 сервер аутентификации, которому доверяет инициатор запроса, расшифровывает EncPub_{AS_REQ}, чтобы получить Cert_REQ и Nonce_REQPub.

[00208] На этапе S508 сервер аутентификации, которому доверяет инициатор запроса, выполняет верификацию легитимности Cert_REQ, чтобы получить Res_REQ, генерирует Pub_REQ в соответствии с информацией, включающей в себя Cert_REQ и Res_REQ, шифрует информацию, включающую в себя Pub_REQ, путем использования Nonce_REQPub, чтобы сгенерировать зашифрованный текст второй информации о результате аутентификации, генерирует Sig_{AS_REQ1} путем выполнения вычисления по подлежащим подписанию данным, включающим в себя зашифрованный текст первой информации о результате аутентификации, и генерирует Sig_{AS_REQ4} путем выполнения вычисления по подлежащим подписанию данным, включающим в себя зашифрованный текст второй информации о результате аутентификации.

[00209] На этапе S509 сервер аутентификации, которому доверяет инициатор запроса, отправляет сигнал AS-REQVeri на сервер аутентификации, которому доверяет контроллер доступа при аутентификации.

[00210] Сообщение AS-REQVeri включает в себя зашифрованный текст первой информации о результате аутентификации, Sig_{AS_REQ1}, зашифрованный текст второй информации о результате аутентификации и Sig_{AS_REQ4}.

[00211] На этапе S510 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, верифицирует Sig_{AS_REQ4} путем использования открытого ключа сервера аутентификации, которому доверяет инициатор запроса.

[00212] Если верификация успешна, выполняется этап S511.

[00213] На этапе S511 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, генерирует Sig_{AS_AAC2} путем выполнения вычисления по подлежащим подписанию данным, включающим в себя зашифрованный текст второй информации о результате аутентификации, и генерирует ASVeri в соответствии с зашифрованным текстом первой информации о результате аутентификации, Sig_{AS_REQ1}, зашифрованным текстом второй информации о результате аутентификации и Sig_{AS_AAC2}.

[00214] На этапе S512 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, отправляет сигнал ASVeri на контроллер доступа при аутентификации.

[00215] На этапе S513 контроллер доступа при аутентификации верифицирует Sig_{AS_AAC2} путем использования открытого ключа сервера аутентификации, которому доверяет контроллер доступа при аутентификации, если верификация успешна, шифрует подлежащие шифрованию данные, включающие в себя зашифрованный текст первой информации о результате аутентификации, Sig_{AS_REQ1} и Nonce_AACPub путем использования ключа шифрования сообщения, чтобы сгенерировать EncData_AAC, и генерирует Sig_AAC путем выполнения вычисления по подлежащим подписанию данным, включающим в себя EncData_AAC.

[00216] На этапе S514 контроллер доступа при аутентификации отправляет третье ответное сообщение AACAuth об аутентификации на инициатор запроса.

[00217] AACAuth включает в себя EncData_AAC и Sig_AAC.

[00218] На этапе S515 инициатор запроса расшифровывает EncData_AAC путем использования ключа шифрования сообщения, чтобы получить зашифрованный текст первой информации о результате аутентификации, Sig_{AS_REQ1} и Nonce_AACPub.

[00219] На этапе S516 инициатор запроса расшифровывает зашифрованный текст первой информации о результате аутентификации путем использования Nonce_AACPub, чтобы получить Pub_AAC.

[00220] На этапе S517 инициатор запроса верифицирует Sig_AAC путем использования Cert_AAC в Pub_AAC и верифицирует Sig_{AS_REQ1} путем использования открытого ключа сервера аутентификации, которому доверяет инициатор запроса.

[00221] Если верификация успешна, затем выполняется этап S518.

[00222] На этапе S518 инициатор запроса определяет результат аутентификации идентификационной информации контроллера доступа при аутентификации в соответствии с Res_AAC в Pub_AAC.

[00223] Когда инициатор запроса определяет, что контроллер доступа при аутентификации легитимен, то выполняется этап S519; и когда инициатор запроса определяет, что контроллер доступа при аутентификации нелегитимен, текущий процесс аутентификации завершается.

[00224] На этапе S519 инициатор запроса шифрует информацию, включающую в себя Nonce_REQPub, путем использования ключа шифрования сообщения, чтобы получить EncData_REQ.

[00225] На этапе S520 инициатор запроса отправляет четвертое ответное сообщение REQAuth об аутентификации на контроллер доступа при аутентификации.

[00226] REQAuth включает в себя EncData_REQ.

[00227] На этапе S521 контроллер доступа при аутентификации расшифровывает EncData_REQ путем использования ключа шифрования сообщения, чтобы получить Nonce_REQPub, и расшифровывает зашифрованный текст второй информации о результате аутентификации путем использования Nonce_REQPub, чтобы получить Pub_REQ.

[00228] На этапе S522 контроллер доступа при аутентификации верифицирует Sig_REQ путем использования Cert_REQ в Pub_REQ.

[00229] Если верификация успешна, выполняется этап S523.

[00230] На этапе S523 контроллер доступа при аутентификации определяет результат аутентификации идентификационной информации инициатора запроса в соответствии с Res_REQ в Pub_REQ.

[00231] Следует отметить, что REQInit на этапе S501 может не включать в себя Sig_REQ, но при этом Sig_REQ добавлен в REQAuth на этапе S520. Другими словами, на этапе S520 инициатор запроса сначала генерирует Sig_REQ путем выполнения вычисления по подлежащим подписанию данным, включающим в себя EncData_REQ в REQAuth. В этом случае Sig_REQ, верифицированная контроллером доступа при аутентификации на этапе S522, представляет собой Sig_REQ в REQAuth на этапе S520.

[00232] На фиг. 6 представлен еще один вариант осуществления способа аутентификации идентификационной информации сервера аутентификации, которому доверяет контроллер доступа при аутентификации, верифицирующего SigAAC и сервера аутентификации, которому доверяет инициатор запроса, верифицирующего SigREQ, в случае наличия роуминга. Перед выполнением этого варианта осуществления и инициатор запроса, и контроллер доступа при аутентификации имеют ключ шифрования сообщения, и ключ шифрования сообщения может быть заранее совместно использован обеими сторонами или может быть получен путем согласования способом, показанным на фиг. 2. Этот способ аутентификации идентификационной информации включает следующие этапы. Этот способ аутентификации идентификационной информации включает следующие этапы.

[00233] На этапе S601 контроллер доступа при аутентификации получает сигнал REQInit, отправленный инициатором запроса.

[00234] REQInit включает в себя EncPub_{AS_REQ} инициатора запроса, ID_{AS_REQ} по меньшей мере одного сервера аутентификации, которому доверяет инициатор запроса, и Sig_REQ инициатора запроса.

[00235] На этапе S602 контроллер доступа при аутентификации отправляет AACVeri на сервер аутентификации, которому доверяет контроллер доступа при аутентификации.

[00236] AACVeri включает в себя REQInit, EncPub_{AS_AAC} контроллера доступа при аутентификации и Sig_AAC контроллера доступа при аутентификации. Sig_AAC генерируют путем выполнения вычислений в других полях перед Sig_AAC в AACVeri.

[00237] На этапе S603 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, расшифровывает EncPub_{AS_AAC}, чтобы получить Cert_AAC и Nonce_AACPub, и верифицирует Sig_AAC путем использования Cert_AAC.

[00238] Если верификация успешна, выполняется этап S604.

[00239] На этапе S604 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, выполняет верификацию легитимности Cert_AAC, чтобы получить Res_AAC, генерирует Pub_AAC в соответствии с информацией, включающей в себя Res_AAC, шифрует информацию, включающую в себя Pub_AAC, путем использования Nonce_AACPub, чтобы сгенерировать зашифрованный текст первой информации о результате аутентификации, и генерирует третью цифровую подпись Sig_{AS_AAC3} путем выполнения вычисления по подлежащим подписанию данным, включающим в себя зашифрованный текст первой информации о результате аутентификации и REQInit.

[00240] На этапе S605 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, отправляет сигнал AS-AACVeri на сервер аутентификации, которому доверяет инициатор запроса.

[00241] Сервер аутентификации, которому доверяет контроллер доступа при аутентификации, выполнен с возможностью определения, в соответствии с ID_{AS_REQ}, сервера аутентификации, которому доверяет инициатор запроса, используемого во время текущего процесса аутентификации, и отправить AS-AACVeri на сервер аутентификации, которому доверяет инициатор запроса. Сигнал AS-AACVeri включает в себя REQInit, зашифрованный текст первой информации о результате аутентификации и Sig_{AS_AAC3}.

[00242] На этапе S606 сервер аутентификации, которому доверяет инициатор запроса, верифицирует Sig_{AS_AAC3} путем использования открытого ключа сервера аутентификации, которому доверяет контроллер доступа при аутентификации.

[00243] Если верификация успешна, затем выполняется этап S607.

[00244] На этапе S607 сервер аутентификации, которому доверяет инициатор запроса, расшифровывает EncPub_{AS_REQ} в REQInit, чтобы получить Cert_REQ и Nonce_REQPub, и верифицирует Sig_REQ путем использования Cert_REQ.

[00245] Если верификация успешна, выполняется этап S608.

[00246] На этапе S608 сервер аутентификации, которому доверяет инициатор запроса, выполняет верификацию легитимности Cert_REQ, чтобы получить Res_REQ, генерирует Pub_REQ в соответствии с информацией, включающей в себя Res_REQ, шифрует информацию, включающую в себя Pub_REQ, путем использования Nonce_REQPub, чтобы сгенерировать зашифрованный текст второй информации о результате аутентификации, генерирует Sig_{AS_REQ1} путем выполнения вычисления по подлежащим подписанию данным, включающим в себя зашифрованный текст первой информации о результате аутентификации, и генерирует Sig_{AS_REQ4} путем выполнения вычисления по подлежащим подписанию данным, включающим в себя зашифрованный текст второй информации о результате аутентификации.

[00247] На этапе S609 сервер аутентификации, которому доверяет инициатор запроса, отправляет сигнал AS-REQVeri на сервер аутентификации, которому доверяет контроллер доступа при аутентификации.

[00248] Сообщение AS-REQVeri включает в себя зашифрованный текст первой информации о результате аутентификации, Sig_{AS_REQ1}, зашифрованный текст второй информации о результате аутентификации и Sig_{AS_REQ4}.

[00249] На этапе S610 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, верифицирует Sig_{AS_REQ4} путем использования открытого ключа сервера аутентификации, которому доверяет инициатор запроса.

[00250] Если верификация успешна, выполняется этап S611.

[00251] На этапе S611 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, генерирует Sig_{AS_AAC2} путем выполнения вычисления по подлежащим подписанию данным, включающим в себя зашифрованный текст второй информации о результате аутентификации, и генерирует ASVeri в соответствии с зашифрованным текстом первой информации о результате аутентификации, Sig_{AS_REQ1}, зашифрованный текст второй информации о результате аутентификации и Sig_{AS_AAC2}.

[00252] На этапе S612 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, отправляет сигнал ASVeri на контроллер доступа при аутентификации.

[00253] На этапе S613 контроллер доступа при аутентификации верифицирует Sig_{AS_AAC2} путем использования открытого ключа сервера аутентификации, которому доверяет контроллер доступа при аутентификации, если верификация успешна, шифрует подлежащие шифрованию данные, включающие в себя зашифрованный текст первой информации о результате аутентификации, Sig_{AS_REQ1} и Nonce_AACPub путем использования ключа шифрования сообщения, чтобы сгенерировать EncData_AAC.

[00254] На этапе S614 контроллер доступа при аутентификации отправляет третье ответное сообщение AACAuth об аутентификации на инициатор запроса.

[00255] AACAuth включает в себя EncData_AAC.

[00256] На этапе S615 инициатор запроса расшифровывает EncData_AAC путем использования ключа шифрования сообщения, чтобы получить зашифрованный текст первой информации о результате аутентификации, Sig_{AS_REQ1} и Nonce_AACPub.

[00257] На этапе S616 инициатор запроса верифицирует Sig_{AS_REQ1} путем использования открытого ключа сервера аутентификации, которому доверяет инициатор запроса.

[00258] Если верификация успешна, затем выполняется этап S617.

[00259] На этапе S617 инициатор запроса расшифровывает зашифрованный текст первой информации о результате аутентификации путем использования Nonce_AACPub, чтобы получить Pub_AAC.

[00260] На этапе S618 инициатор запроса определяет результат аутентификации идентификационной информации контроллера доступа при аутентификации в соответствии с Res_AAC в Pub_AAC.

[00261] Когда инициатор запроса определяет, что контроллер доступа при аутентификации легитимен, то выполняется этап S619; и когда инициатор запроса определяет, что контроллер доступа при аутентификации нелегитимен, текущий процесс аутентификации завершается.

[00262] На этапе S619 инициатор запроса шифрует информацию, включающую в себя Nonce_REQPub, путем использования ключа шифрования сообщения, чтобы получить EncData_REQ.

[00263] На этапе S620 инициатор запроса отправляет четвертое ответное сообщение REQAuth об аутентификации на контроллер доступа при аутентификации.

[00264] REQAuth включает в себя EncData_REQ.

[00265] На этапе S621 контроллер доступа при аутентификации расшифровывает EncData_REQ путем использования ключа шифрования сообщения, чтобы получить Nonce_REQPub, и расшифровывает зашифрованный текст второй информации о результате аутентификации путем использования Nonce_REQPub, чтобы получить Pub_REQ.

[00266] На этапе S622 контроллер доступа при аутентификации определяет результат аутентификации идентификационной информации инициатора запроса в соответствии с Res_REQ в Pub_REQ.

[00267] На фиг. 7 представлен еще один вариант осуществления способа аутентификации идентификационной информации в случае отсутствия роуминга. Сервер аутентификации, которому доверяет контроллер доступа при аутентификации (или сервер аутентификации, которому доверяет инициатор запроса), может использоваться для представления сервера аутентификации, которому обычно доверяют инициатор запроса и контроллер доступа при аутентификации. В этом варианте осуществления процесс согласования ключа шифрования сообщения между инициатором запроса и контроллером доступа при аутентификации объединен с процессом аутентификации идентификационной информации в режиме параллельного выполнения, благодаря чему облегчается реализация проекта. Sig_REQ верифицируется контроллером доступа при аутентификации, а Sig_AAC верифицируется инициатором запроса. Этот способ включает следующие этапы.

[00268] На этапе S701 контроллер доступа при аутентификации генерирует Nonce_AAC и KeyInfo_AAC, и генерирует средства безопасности_AAC в соответствии с требованиями.

[00269] На этапе S702 контроллер доступа при аутентификации отправляет AACInit на инициатор запроса.

[00270] AACInit включает в себя Nonce_AAC, KeyInfo_AAC и средства безопасности_AAC. Поле «средства безопасности_AAC» является необязательным, представляет информацию о параметре средства безопасности, поддерживаемом контроллером доступа при аутентификации, и включает в себя пакет аутентификации идентификационной информации, поддерживаемый контроллером доступа при аутентификации, один или более алгоритмов симметричного шифрования, один или более алгоритмов проверки целостности и/или один или более алгоритмов формирования ключа (что также относится ко всему тексту).

[00271] На этапе S703 инициатор запроса генерирует Nonce_REQ, KeyInfo_REQ, Nonce_REQID и Nonce_REQPub, генерирует средства безопасности_REQ в соответствии с требованиями и выполняет вычисление обмена ключами в соответствии с временным закрытым ключом, соответствующим KeyInfo_REQ, и временным открытым ключом, включенным в KeyInfo_AAC, чтобы сгенерировать первый ключ K1; причем K1 объединяют с Nonce_AAC, Nonce_REQ и другой информацией (другая информация, используемая инициатором запроса и контроллером доступа при аутентификации, является одинаковой и необязательной, например, определенная строка), чтобы вычислить ключ шифрования сообщения и ключ проверки целостности сообщения путем использования согласованного или заранее заданного алгоритма формирования ключа, конечно, этот этап также может быть выполнен, когда ключ проверки целостности сообщения и/или ключ проверки целостности сообщения необходимо использовать позже; открытый ключ сертификата шифрования используют для вычисления EncPub_{AS_REQ} инициатора запроса; и вычисляют Sig_REQ.

[00272] Поле «средства безопасности_REQ» является необязательным и указывает на выбор определенной политики безопасности, сделанный инициатором запроса, в соответствии со средствами безопасности_REQ, т.е. способом аутентификации идентификационной информации, алгоритмом симметричного шифрования, алгоритмом проверки целостности и/или алгоритмом формирования ключа (что также относится ко всему тексту), которые определены, как подлежащие использованию инициатором запроса. Генерирует ли инициатор запроса средства безопасности_REQ, зависит от того, содержатся ли средства безопасности_AAC в AACInit, отправленном контроллером доступа при аутентификации на инициатор запроса.

[00273] На этапе S704 инициатор запроса отправляет REQInit на контроллер доступа при аутентификации.

[00274] REQInit включает в себя Nonce_AAC, Nonce_REQ, средства безопасности_REQ, KeyInfo_REQ, EncPub_{AS_REQ} и Sig_REQ. Поля «Nonce_AAC» и «средства безопасности_REQ» являются необязательными; а Nonce_AAC должно быть идентичным имеющемуся в соответствующем поле в AACInit. Подлежащие шифрованию данные EncPub_{AS_REQ} включают в себя ID_REQ, Cert_REQ, Nonce_REQID и Nonce_REQPub. Подлежащие подписанию данные Sig_REQ включают в себя другие поля перед Sig_REQ в REQInit. Например, когда REQInit последовательно включает в себя Nonce_AAC, Nonce_REQ, средства безопасности_REQ, KeyInfo_REQ, EncPub_{AS_REQ} и Sig_REQ, подлежащие подписанию данные Sig_REQ включают в себя Nonce_AAC, Nonce_REQ, средства безопасности_REQ, KeyInfo_REQ и EncPub_{AS_REQ}; кроме того, когда REQInit не включает в себя поле «Nonce_AAC», подлежащие подписанию данные Sig_REQ дополнительно включают в себя поле «Nonce_AAC» в AACInit. В настоящем раскрытии объект, подлежащий наложению подписи, упоминается как подлежащие подписанию данные.

[00275] На этапе S705 после приема REQInit контроллер доступа при аутентификации выполняет следующие операции (если нет специального объяснения или логической взаимосвязи, действия, пронумерованные (1), (2),... в этом описании, не обязательно имеют последовательный порядок, соответствующий их нумерации, что также относится ко всему тексту).

[00276] (1) Если в REQInit содержится Nonce_AAC, выполняет проверку того, является ли это Nonce_AAC таким же, как Nonce_AAC, сгенерированное контроллером доступа при аутентификации; и если это Nonce_AAC отличается от Nonce_AAC, сгенерированного контроллером доступа при аутентификации, отбрасывает REQInit.

[00277] (2) Выполняет вычисление обмена ключами в соответствии с временным закрытым ключом, соответствующим KeyInfo_AAC, и временным открытым ключом, включенным в KeyInfo_REQ, чтобы сгенерировать первый ключ K1; причем K1 объединяют с Nonce_AAC, Nonce_REQ и другой информацией (другая информация, используемая инициатором запроса и контроллером доступа при аутентификации, является одинаковой и необязательной, например, определенная строка), чтобы вычислить ключ шифрования сообщения и ключ проверки целостности сообщения путем использования согласованного или заранее заданного алгоритма формирования ключа. Конечно, этот этап может быть выполнен, когда ключ проверки целостности сообщения и/или ключ проверки целостности сообщения должны использоваться контроллером доступа при аутентификации.

[00278] (3) Генерирует Nonce_AACID и Nonce_AACPub.

[00279] (4) Использует открытый ключ сертификата шифрования для вычисления EncPub_{AS_AAC}.

[00280] На этапе S706 контроллер доступа при аутентификации отправляет AACVeri на сервер аутентификации, которому доверяет контроллер доступа при аутентификации.

[00281] AACVeri включает в себя EncPub_{AS_REQ}, Nonce_REQ, EncPub_{AS_AAC} и Nonce_AAC. Подлежащие шифрованию данные EncPub_{AS_AAC} включают в себя ID_AAC, Cert_AAC, Nonce_AACID и Nonce_AACPub; а EncPub_{AS_REQ} и Nonce_REQ, соответственно, должны быть идентичными имеющимся в соответствующих полях в REQInit.

[00282] На этапе S707 после приема AACVeri сервер аутентификации, которому доверяет контроллер доступа при аутентификации, выполняет следующие операции.

[00283] (1) Использует закрытый ключ, соответствующий сертификату шифрования, для расшифровки, соответственно, EncPub_{AS_REQ} и EncPub_{AS_AAC}, чтобы получить ID_REQ, Cert_REQ, Nonce_REQID, Nonce_REQPub, ID_AAC, Cert_AAC, Nonce_AACID и Nonce_AACPub.

[00284] (2) Верифицирует легитимность Cert_AAC и Cert_REQ, соответственно, для получения Res_AAC и Res_REQ; генерирует Pub_AAC в соответствии с информацией, включающей в себя Cert_AAC и Res_AAC; генерирует Pub_REQ в соответствии с информацией, включающей в себя Cert_REQ и Res_REQ; в отношении ID_REQ и Nonce_REQID выполняет операцию «исключающего или», чтобы сгенерировать ID_REQ⊕Nonce_REQID; в отношении Pub_REQ и Nonce_REQPub выполняет операцию «исключающего или», чтобы сгенерировать Pub_REQ⊕Nonce_REQPub; в отношении ID_AAC и Nonce_AACID выполняет операцию «исключающего или», чтобы сгенерировать ID_AAC⊕Nonce_AACID; и в отношении Pub_AAC и Nonce_AACPub выполняет операцию «исключающего или», чтобы сгенерировать Pub_AAC⊕Nonce_AACPub.

[00285] (3) Генерирует Sig_{AS_AAC1} и Sig_{AS_AAC2} путем вычисления.

[00286] На этапе S708 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, отправляет сигнал ASVeri на контроллер доступа при аутентификации.

[00287] ASVeri включает в себя ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub, Sig_{AS_AAC1}, ID_AAC⊕Nonce_AACID, Nonce_AAC, Pub_REQ⊕Nonce_REQPub и Sig_{AS_AAC2}. ID_REQ, Nonce_REQID, Nonce_REQ, Nonce_AACPub, ID_AAC, Nonce_AACID, Nonce_AAC и Nonce_REQPub, соответственно, должны быть идентичными имеющимся в соответствующих полях в AACVeri. Подлежащие подписанию данные Sig_{AS_AAC1} включают в себя ID_REQ⊕Nonce_REQID, Nonce_REQ и Pub_AAC⊕Nonce_AACPub; а подлежащие подписанию данные Sig_{AS_AAC2} включают в себя ID_AAC⊕Nonce_AACID, Nonce_AAC и Pub_REQ⊕Nonce_REQPub.

[00288] На этапе S709 после приема ASVeri контроллер доступа при аутентификации выполняет следующие операции.

[00289] (1) В отношении Nonce_AACID и ID_AAC⊕Nonce_AACID выполняет операцию «исключающего или», чтобы восстановить ID_AAC, и выполняет проверку того, является ли ID_AAC таким же, как собственный ID_AAC контроллера доступа при аутентификации.

[00290] (2) Выполняет проверку того, является ли Nonce_AAC таким же, как Nonce_AAC, сгенерированное контроллером доступа при аутентификации.

[00291] (3) Верифицирует Sig_{AS_AAC2} путем использования открытого ключа сервера аутентификации, которому доверяет контроллер доступа при аутентификации.

[00292] (4) Если проверка и верификация успешны, вычисляет EncData_AAC путем использования ключа шифрования сообщения; и если какой-либо из этапов проверки и верификации не был успешным, немедленно отбрасывает ASVeri.

[00293] (5) Вычисляет Sig_AAC.

[00294] (6) Вычисляет MacTag_AAC в соответствии с требованиями.

[00295] На этапе S710 контроллер доступа при аутентификации отправляет третье ответное сообщение AACAuth об аутентификации на инициатор запроса.

[00296] AACAuth включает в себя Nonce_REQ, Nonce_AAC, EncData_AAC, Sig_AAC и MacTag_AAC. Поля «Nonce_REQ», «Nonce_AAC» и «MacTag_AAC» являются необязательными; а Nonce_REQ и Nonce_AAC, соответственно, должны быть идентичными Nonce_REQ в REQInit и Nonce_AAC, сгенерированному контроллером доступа при аутентификации. Подлежащие шифрованию данные EncData_AAC включают в себя ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub, Sig_{AS_AAC1} и Nonce_AACPub; а ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub и Sig_{AS_AAC1}, соответственно, должны быть идентичными имеющимся в соответствующих полях в ASVeri. Подлежащие подписанию данные Sig_AAC включают в себя другие поля перед Sig_AAC в AACAuth. Процесс вычисления MacTag_AAC включает: использование ключа проверки целостности сообщения для вычисления информации, включающей в себя поля в AACAuth, отличные от MacTag_AAC, путем использования алгоритма проверки целостности, чтобы сгенерировать MacTag_AAC.

[00297] На этапе S711 после приема AACAuth инициатор запроса выполняет следующие операции.

[00298] (1) Если в AACAuth содержится Nonce_REQ и/или Nonce_AAC, выполняет проверку того, является ли Nonce_REQ таким же, как Nonce_REQ, сгенерированное инициатором запроса; и/или выполняет проверку того, является ли Nonce_AAC таким же, как принятое Nonce_AAC в AACInit.

[00299] (2) Если в AACAuth содержится MacTag_AAC, выполняет верификацию MacTag_AAC.

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

[00301] (3) Использует ключ шифрования сообщения для расшифровки EncData_AAC путем использования алгоритма симметричного шифрования, чтобы получить ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub, Sig_{AS_AAC1} и Nonce_AACPub.

[00302] (4) В отношении ID_REQ⊕Nonce_REQID выполняет операцию «исключающего или» путем использования Nonce_REQID, чтобы восстановить ID_REQ, и выполняет проверку того, является ли ID_REQ таким же, как собственный ID_REQ инициатора запроса.

[00303] (5) Выполняет проверку того, является ли Nonce_REQ таким же, как Nonce_REQ, сгенерированное инициатором запроса.

[00304] (6) В отношении Nonce_AACPub и Pub_AAC⊕Nonce_AACPub, полученных путем расшифровки, выполняет операцию «исключающего или», чтобы восстановить Pub_AAC.

[00305] (7) Верифицирует Sig_{AS_AAC1} путем использования открытого ключа сервера аутентификации, которому доверяет контроллер доступа при аутентификации, и верифицирует Sig_AAC путем использования Cert_AAC в Pub_AAC.

[00306] (8) Если какой-либо из этапов проверки и верификации не был успешным, немедленно отбрасывает AACAuth; если проверка и верификация успешны, определяет результат аутентификации идентификационной информации инициатора запроса в соответствии с Res_AAC в Pub_AAC; и если определяет, что контроллер доступа при аутентификации нелегитимен, завершает текущий процесс аутентификации.

[00307] (9) Использует ключ шифрования сообщения для вычисления EncData_REQ.

[00308] (10) Вычисляет MacTag_REQ.

[00309] На этапе S712 инициатор запроса отправляет четвертое ответное сообщение REQAuth об аутентификации на контроллер доступа при аутентификации.

[00310] AACAuth включает в себя Nonce_REQ, Nonce_AAC, EncData_REQ и MacTag_REQ. Поля «Nonce_REQ» и «Nonce_AAC» являются необязательными; и, соответственно, должны быть идентичными Nonce_REQ, сгенерированному инициатором запроса, и Nonce_AAC в AACInit. Подлежащие шифрованию данные EncData_REQ включают в себя Nonce_REQPub. Процесс вычисления MacTag_REQ включает: использование ключа проверки целостности сообщения для вычисления информации, включающей в себя поля в REQAuth, отличные от MacTag_REQ, путем использования алгоритма проверки целостности, чтобы сгенерировать MacTag_REQ.

[00311] На этапе S713 после приема REQAuth контроллер доступа при аутентификации выполняет следующие операции.

[00312] (1) Если в REQAuth содержится Nonce_REQ и/или Nonce_AAC, выполняет проверку того, является ли Nonce_REQ таким же, как Nonce_REQ в REQInit; и/или выполняет проверку того, является ли Nonce_AAC таким же, как Nonce_AAC, сгенерированное контроллером доступа при аутентификации.

[00313] (2) Выполняет верификацию MacTag_REQ.

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

[00315] (3) Использует ключ шифрования сообщения для расшифровки EncData_REQ путем использования алгоритма симметричного шифрования, чтобы получить Nonce_REQPub.

[00316] (4) В отношении Nonce_REQPub и Pub_REQ⊕Nonce_REQPub выполняет операцию «исключающего или», чтобы восстановить Pub_REQ.

[00317] (5) Верифицирует Sig_REQ в REQInit путем использования Cert_REQ в Pub_REQ.

[00318] (6) Если какой-либо из этапов проверки и верификации не был успешным, немедленно отбрасывает REQAuth; если проверка и верификация успешны, определяет результат аутентификации идентификационной информации инициатора запроса в соответствии с Res_REQ в Pub_REQ.

[00319] Следует отметить, что REQInit на этапе S704 может не включать в себя Sig_REQ, но при этом Sig_REQ добавлен в REQAuth на этапе S712. Другими словами, на этапе S712 инициатор запроса сначала генерирует Sig_REQ путем выполнения вычисления по подлежащим подписанию данным, включающим в себя Nonce_REQ, Nonce_AAC и EncData_REQ. В этом случае Sig_REQ, верифицированная контроллером доступа при аутентификации на этапе S713, представляет собой Sig_REQ в REQAuth на этапе S712.

[00320] На фиг. 8 представлен еще один вариант осуществления способа аутентификации идентификационной информации в случае отсутствия роуминга. Сервер аутентификации, которому доверяет контроллер доступа при аутентификации (или сервер аутентификации, которому доверяет инициатор запроса), может использоваться для представления сервера аутентификации, которому обычно доверяют инициатор запроса и контроллер доступа при аутентификации. В этом варианте осуществления процесс согласования ключа шифрования сообщения между инициатором запроса и контроллером доступа при аутентификации объединен с процессом аутентификации идентификационной информации в режиме параллельного выполнения, благодаря чему облегчается реализация проекта. Sig_REQ и Sig_AAC верифицируются сервером аутентификации, которому доверяет контроллер доступа при аутентификации. Этот способ включает следующие этапы.

[00321] На этапе S801 контроллер доступа при аутентификации генерирует Nonce_AAC и KeyInfo_AAC, и генерирует средства безопасности_AAC в соответствии с требованиями.

[00322] На этапе S802 контроллер доступа при аутентификации отправляет AACInit на инициатор запроса.

[00323] AACInit включает в себя Nonce_AAC, KeyInfo_AAC и средства безопасности_AAC. Поле «средства безопасности_AAC» является необязательным.

[00324] На этапе S803 инициатор запроса генерирует Nonce_REQ, KeyInfo_REQ, Nonce_REQID и Nonce_REQPub, генерирует средства безопасности_REQ в соответствии с требованиями и выполняет вычисление обмена ключами в соответствии с временным закрытым ключом, соответствующим KeyInfo_REQ, и временным открытым ключом, включенным в KeyInfo_AAC, чтобы сгенерировать первый ключ K1; причем K1 объединяют с Nonce_AAC, Nonce_REQ и другой информацией (другая информация, используемая инициатором запроса и контроллером доступа при аутентификации, является одинаковой и необязательной, например, определенная строка), чтобы вычислить ключ шифрования сообщения и ключ проверки целостности сообщения путем использования согласованного или заранее заданного алгоритма формирования ключа, конечно, этот этап также может быть выполнен, когда ключ проверки целостности сообщения и/или ключ проверки целостности сообщения необходимо использовать позже; открытый ключ сертификата шифрования используют для вычисления EncPub_{AS_REQ} инициатора запроса; и вычисляют Sig_REQ.

[00325] На этапе S804 инициатор запроса отправляет REQInit на контроллер доступа при аутентификации.

[00326] REQInit включает в себя Nonce_AAC, Nonce_REQ, средства безопасности_REQ, KeyInfo_REQ, EncPub_{AS_REQ} и Sig_REQ. Поле «средства безопасности_REQ» является необязательным; а Nonce_AAC должно быть идентичным имеющемуся в соответствующем поле в AACInit. Подлежащие шифрованию данные EncPub_{AS_REQ} включают в себя ID_REQ, Cert_REQ, Nonce_REQID и Nonce_REQPub. Подлежащие подписанию данные Sig_REQ включают в себя другие поля перед Sig_REQ в REQInit.

[00327] На этапе S805 после приема REQInit контроллер доступа при аутентификации выполняет следующие операции.

[00328] (1) Выполняет проверку того, является ли Nonce_AAC в REQInit таким же, как Nonce_AAC, сгенерированное контроллером доступа при аутентификации; и если это не так, отбрасывает REQInit.

[00329] (2) Выполняет вычисление обмена ключами в соответствии с временным закрытым ключом, соответствующим KeyInfo_AAC, и временным открытым ключом, включенным в KeyInfo_REQ, чтобы сгенерировать первый ключ K1; причем K1 объединяют с Nonce_AAC, Nonce_REQ и другой информацией (другая информация, используемая инициатором запроса и контроллером доступа при аутентификации, является одинаковой и необязательной, например, определенная строка), чтобы вычислить ключ шифрования сообщения и ключ проверки целостности сообщения путем использования согласованного или заранее заданного алгоритма формирования ключа. Конечно, этот этап может быть выполнен, когда ключ проверки целостности сообщения и/или ключ проверки целостности сообщения должны использоваться контроллером доступа при аутентификации.

[00330] (3) Генерирует Nonce_AACID и Nonce_AACPub.

[00331] (4) Использует открытый ключ сертификата шифрования для вычисления EncPub_{AS_AAC}.

[00332] (5) Вычисляет Sig_AAC.

[00333] На этапе S806 контроллер доступа при аутентификации отправляет AACVeri на сервер аутентификации, которому доверяет контроллер доступа при аутентификации.

[00334] AACVeri включает в себя REQInit, EncPub_{AS_AAC} и Sig_AAC. Подлежащие шифрованию данные EncPub_{AS_AAC} включают в себя ID_AAC, Cert_AAC, Nonce_AACID и Nonce_AACPub. Подлежащие подписанию данные Sig_AAC включают в себя другие поля перед Sig_AAC в AACVeri.

[00335] На этапе S807 после приема AACVeri сервер аутентификации, которому доверяет контроллер доступа при аутентификации, выполняет следующие операции.

[00336] (1) Использует закрытый ключ, соответствующий сертификату шифрования, для расшифровки, соответственно, EncPub_{AS_AAC} и EncPub_{AS_REQ} в REQInit, чтобы получить ID_AAC, Cer_tAAC, Nonce_AACID, Nonce_AACPub, ID_REQ, Cert_REQ, Nonce_REQID и Nonce_REQPub.

[00337] (2) Верифицирует Sig_REQ в REQInit путем использования Cert_REQ; и верифицирует Sig_AAC путем использования Cert_AAC.

[00338] (3) Если верификация успешна, верифицирует легитимность Cert_AAC и Cert_REQ, соответственно, для получения Res_AAC и Res_REQ; генерирует Pub_AAC в соответствии с информацией, включающей в себя Res_AAC; генерирует Pub_REQ в соответствии с информацией, включающей в себя Res_REQ; в отношении ID_REQ и Nonce_REQID выполняет операцию «исключающего или», чтобы сгенерировать ID_REQ⊕Nonce_REQID; в отношении Pub_REQ и Nonce_REQPub выполняет операцию «исключающего или», чтобы сгенерировать Pub_REQ⊕Nonce_REQPub; в отношении ID_AAC и Nonce_AACID выполняет операцию «исключающего или», чтобы сгенерировать ID_AAC⊕Nonce_AACID; и в отношении Pub_AAC и Nonce_AACPub выполняет операцию «исключающего или», чтобы сгенерировать Pub_AAC⊕Nonce_AACPub.

[00339] (4) Генерирует Sig_{AS_AAC1} и Sig_{AS_AAC2} путем вычисления.

[00340] На этапе S808 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, отправляет сигнал ASVeri на контроллер доступа при аутентификации.

[00341] ASVeri включает в себя ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub, Sig_{AS_AAC1}, ID_AAC⊕Nonce_AACID, Nonce_AAC, Pub_REQ⊕Nonce_REQPub и Sig_{AS_AAC2}. ID_REQ, Nonce_REQID, Nonce_REQ, Nonce_AACPub, ID_AAC, Nonce_AACID, Nonce_AAC и Nonce_REQPub, соответственно, должны быть идентичными имеющимся в соответствующих полях в AACVeri. Подлежащие подписанию данные Sig_{AS_AAC1} включают в себя ID_REQ⊕Nonce_REQID, Nonce_REQ и Pub_AAC⊕Nonce_AACPub; а подлежащие подписанию данные Sig_{AS_AAC2} включают в себя ID_AAC⊕Nonce_AACID, Nonce_AAC и Pub_REQ⊕Nonce_REQPub.

[00342] На этапе S809 после приема ASVeri контроллер доступа при аутентификации выполняет следующие операции.

[00343] (1) В отношении Nonce_AACID и ID_AAC⊕Nonce_AACID выполняет операцию «исключающего или», чтобы восстановить ID_AAC, и выполняет проверку того, является ли ID_AAC таким же, как собственный ID_AAC контроллера доступа при аутентификации.

[00344] (2) Выполняет проверку того, является ли Nonce_AAC таким же, как Nonce_AAC, сгенерированное контроллером доступа при аутентификации.

[00345] (3) Верифицирует Sig_{AS_AAC2} путем использования открытого ключа сервера аутентификации, которому доверяет контроллер доступа при аутентификации.

[00346] (4) Если проверка и верификация успешны, вычисляет EncData_AAC путем использования ключа шифрования сообщения; и если какой-либо из этапов проверки и верификации не был успешным, немедленно отбрасывает ASVeri.

[00347] (5) Вычисляет MacTag_AAC.

[00348] На этапе S810 контроллер доступа при аутентификации отправляет третье ответное сообщение AACAuth об аутентификации на инициатор запроса.

[00349] AACAuth включает в себя Nonce_REQ, Nonce_AAC, EncData_AAC и MacTag_AAC. Поля «Nonce_REQ» и «Nonce_AAC» являются необязательными; и, соответственно, должны быть идентичными Nonce_REQ в REQInit, сгенерированному инициатором запроса, и Nonce_AAC, сгенерированному контроллером доступа при аутентификации. Подлежащие шифрованию данные EncData_AAC включают в себя ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub, Sig_{AS_AAC1} и Nonce_AACPub; а ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub и Sig_{AS_AAC1}, соответственно, должны быть идентичными имеющимся в соответствующих полях в ASVeri. Процесс вычисления MacTag_AAC описан в варианте осуществления по фиг. 7.

[00350] На этапе S811 после приема AACAuth инициатор запроса выполняет следующие операции.

[00351] (1) Если в AACAuth содержится Nonce_REQ и/или Nonce_AAC, выполняет проверку того, является ли Nonce_REQ таким же, как Nonce_REQ, сгенерированное инициатором запроса; и/или выполняет проверку того, является ли Nonce_AAC таким же, как принятое Nonce_AAC в AACInit.

[00352] (2) Верифицирует MacTag_AAC; процесс верификации описан в варианте осуществления по фиг. 7.

[00353] (3) Использует ключ шифрования сообщения для расшифровки EncData_AAC путем использования алгоритма симметричного шифрования, чтобы получить ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub, Sig_{AS_AAC1} и Nonce_AACPub.

[00354] (4) В отношении ID_REQ⊕Nonce_REQID выполняет операцию «исключающего или» путем использования Nonce_REQID, чтобы восстановить ID_REQ, и выполняет проверку того, является ли ID_REQ таким же, как собственный ID_REQ инициатора запроса.

[00355] (5) Выполняет проверку того, является ли Nonce_REQ таким же, как Nonce_REQ, сгенерированное инициатором запроса.

[00356] (6) Верифицирует Sig_{AS_AAC1} путем использования открытого ключа сервера аутентификации, которому доверяет контроллер доступа при аутентификации.

[00357] (7) Если какой-либо из этапов проверки и верификации не был успешным, немедленно отбрасывает AACAuth; если проверка и верификация успешны, в отношении Nonce_AACPub и Pub_AAC⊕Nonce_AACPub, полученных путем расшифровки, выполняет операцию «исключающего или», чтобы восстановить Pub_AAC; определяет результат аутентификации идентификационной информации инициатора запроса в соответствии с Res_AAC в Pub_AAC; и если определяет, что контроллер доступа при аутентификации нелегитимен, завершает текущий процесс аутентификации.

[00358] (8) Использует ключ шифрования сообщения для вычисления EncData_REQ.

[00359] (9) Вычисляет MacTag_REQ.

[00360] На этапе S812 инициатор запроса отправляет четвертое ответное сообщение REQAuth об аутентификации на контроллер доступа при аутентификации.

[00361] REQAuth включает в себя Nonce_AAC, Nonce_REQ, EncData_REQ и MacTag_REQ. Поля «Nonce_REQ» и «Nonce_AAC» являются необязательными; и, соответственно, должны быть идентичными Nonce_REQ, сгенерированному инициатором запроса, и Nonce_AAC в AACInit. Подлежащие шифрованию данные EncData_REQ включают в себя Nonce_REQPub. Процесс вычисления MacTag_REQ описан в варианте осуществления по фиг. 7.

[00362] На этапе S813 после приема REQAuth контроллер доступа при аутентификации выполняет следующие операции.

[00363] (1) Если в REQAuth содержится Nonce_REQ и/или Nonce_AAC, выполняет проверку того, является ли Nonce_REQ таким же, как Nonce_REQ в REQInit; и/или выполняет проверку того, является ли Nonce_AAC таким же, как Nonce_AAC, сгенерированное контроллером доступа при аутентификации.

[00364] (2) Верифицирует MacTag_REQ; и процесс верификации описан в варианте осуществления по фиг. 7.

[00365] (3) Если проверка и верификация успешны, использует ключ шифрования сообщения для расшифровки EncData_REQ путем использования алгоритма симметричного шифрования, чтобы получить Nonce_REQPub; и если какой-либо из этапов проверки и верификации не был успешным, немедленно отбрасывает REQAuth.

[00366] (4) В отношении Nonce_REQPub и Pub_REQ⊕Nonce_REQPub выполняет операцию «исключающего или», чтобы восстановить Pub_REQ.

[00367] (5) Определяет результат аутентификации идентификационной информации инициатора запроса в соответствии с Res_REQ в Pub_REQ.

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

[00369] На этапе S901 контроллер доступа при аутентификации генерирует Nonce_AAC и KeyInfo_AAC, и генерирует средства безопасности_AAC в соответствии с требованиями.

[00370] На этапе S902 контроллер доступа при аутентификации отправляет AACInit на инициатор запроса.

[00371] AACInit включает в себя Nonce_AAC, KeyInfo_AAC, ID_{AS_AAC} и средства безопасности_AAC. Поле «Средства безопасности_AAC» является необязательным; и поле «ID_{AS_AAC}» является необязательным и представляет собой идентификационный идентификатор по меньшей мере одного сервера аутентификации, которому доверяет контроллер доступа при аутентификации, чтобы инициатор запроса определил, в соответствии с ID_{AS_AAC}, существует ли сервер аутентификации с общим доверием (что также относится ко всему тексту).

[00372] На этапе S903 инициатор запроса генерирует Nonce_REQ, KeyInfo_REQ, Nonce_REQID и Nonce_REQPub, генерирует ID_{AS_REQ} и средства безопасности_REQ в соответствии с требованиями и выполняет вычисление обмена ключами в соответствии с временным закрытым ключом, соответствующим KeyInfo_REQ, и временным открытым ключом, включенным в KeyInfo_AAC, чтобы сгенерировать первый ключ K1; причем K1 объединяют с Nonce_AAC, Nonce_REQ и другой информацией (другая информация, используемая инициатором запроса и контроллером доступа при аутентификации, является одинаковой и необязательной, например, определенная строка), чтобы вычислить ключ шифрования сообщения и ключ проверки целостности сообщения путем использования согласованного или заранее заданного алгоритма формирования ключа, конечно, этот этап также может быть выполнен, когда ключ проверки целостности сообщения и/или ключ проверки целостности сообщения необходимо использовать позже; открытый ключ сертификата шифрования используют для вычисления EncPub_{AS_REQ} инициатора запроса; и вычисляют Sig_REQ.

[00373] Поля «ID_{AS_REQ}» и «средства безопасности_AAC» являются необязательными. ID_{AS_REQ} представляет собой идентификационный идентификатор по меньшей мере одного сервера аутентификации, которому доверяет инициатор запроса, когда в AACInit содержится ID_{AS_AAC}, инициатор запроса пытается выбрать из доверенных серверов аутентификации по меньшей мере один сервер аутентификации, который является таким же, который содержится в ID_{AS_AAC}, в качестве ID_{AS_REQ}; если этот выбор не был успешным, по меньшей мере один доверенный сервер аутентификации в качестве ID_{AS_REQ}; и когда в AACInit не содержится ID_{AS_AAC}, инициатор запроса использует по меньшей мере один доверенный сервер аутентификации в качестве ID_{AS_REQ} (что также применяется в дальнейшем).

[00374] На этапе S904 инициатор запроса отправляет REQInit на контроллер доступа при аутентификации.

[00375] REQInit включает в себя Nonce_AAC, Nonce_REQ, ID_{AS_REQ}, средства безопасности_REQ, KeyInfo_REQ, EncPub_{AS_REQ} и Sig_REQ. Поля «Nonce_AAC», «ID_{AS_REQ}» и средства безопасности_REQ» являются необязательными; а Nonce_AAC должно быть идентичным имеющемуся в соответствующем поле в AACInit. Подлежащие шифрованию данные EncPub_{AS_REQ} включают в себя ID_REQ, Cert_REQ, Nonce_REQID и Nonce_REQPub. Подлежащие подписанию данные Sig_REQ включают в себя другие поля перед Sig_REQ в REQInit. Когда REQInit не включает в себя поле «Nonce_AAC», подлежащие подписанию данные Sig_REQ дополнительно включают в себя поле «Nonce_AAC» в AACInit.

[00376] На этапе S905 после приема REQInit контроллер доступа при аутентификации выполняет следующие операции.

[00377] (1) Если в REQInit содержится Nonce_AAC, выполняет проверку того, является ли это Nonce_AAC таким же, как Nonce_AAC, сгенерированное контроллером доступа при аутентификации; и если это Nonce_AAC отличается от Nonce_AAC, сгенерированного контроллером доступа при аутентификации, отбрасывает REQInit.

[00378] (2) Выполняет вычисление обмена ключами в соответствии с временным закрытым ключом, соответствующим KeyInfo_AAC, и временным открытым ключом, включенным в KeyInfo_REQ, чтобы сгенерировать первый ключ K1; причем K1 объединяют с Nonce_AAC, Nonce_REQ и другой информацией (другая информация, используемая инициатором запроса и контроллером доступа при аутентификации, является одинаковой и необязательной, например, определенная строка), чтобы вычислить ключ шифрования сообщения и ключ проверки целостности сообщения путем использования согласованного или заранее заданного алгоритма формирования ключа. Конечно, этот этап может быть выполнен, когда ключ проверки целостности сообщения и/или ключ проверки целостности сообщения должны использоваться контроллером доступа при аутентификации.

[00379] (3) Генерирует Nonce_AACID и Nonce_AACPub.

[00380] (4) Использует открытый ключ сертификата шифрования для вычисления EncPub_{AS_AAC}.

[00381] (5) Если REQInit содержит ID_{AS_REQ}, а AACInit содержит ID_{AS_AAC}, контроллер доступа при аутентификации определяет, имеется ли идентификационный идентификатор по меньшей мере одного и того же сервера аутентификации в ID_{AS_REQ} и ID_{AS_AAC}; если это так, т.е. в случае отсутствия роуминга, контроллер доступа при аутентификации определяет сервер аутентификации, которому доверяет контроллер доступа при аутентификации, участвующий в аутентификации идентификационной информации, по идентификационному идентификатору сервера аутентификации, которому обычно доверяют по меньшей мере один инициатор запроса и контроллер доступа при аутентификации; и если это не так, т.е. в случае наличия роуминга, контроллер доступа при аутентификации должен определить, в соответствии с ID_{AS_AAC}, сервер аутентификации, которому доверяет контроллер доступа при аутентификации, участвующий в аутентификации идентификационной информации, и отправляет ID_{AS_REQ} на сервер аутентификации, которому доверяет контроллер доступа при аутентификации, таким образом, сервер аутентификации, которому доверяет контроллер доступа при аутентификации, определяет сервер аутентификации, которому доверяет инициатор запроса, в соответствии с ID_{AS_REQ}.

[00382] Альтернативно, если REQInit содержит ID_{AS_REQ}, но AACInit не содержит ID_{AS_AAC}, контроллер доступа при аутентификации определяет, имеется ли идентификационный идентификатор по меньшей мере одного и того же сервера аутентификации в числе серверов аутентификации, которые являются доверенными для ID_{AS_REQ} и контроллера доступа при аутентификации; если это так, т.е. в случае отсутствия роуминга, контроллер доступа при аутентификации определяет сервер аутентификации, которому доверяет контроллер доступа при аутентификации, участвующий в аутентификации идентификационной информации, по идентификационному идентификатору сервера аутентификации, которому обычно доверяют по меньшей мере один инициатор запроса и контроллер доступа при аутентификации; и если это не так, т.е. в случае наличия роуминга, контроллер доступа при аутентификации должен определить, в соответствии с сервером аутентификации, которому доверяет контроллер доступа при аутентификации, сервер аутентификации, которому доверяет контроллер доступа при аутентификации, участвующий в аутентификации идентификационной информации, и отправляет ID_{AS_REQ} на сервер аутентификации, которому доверяет контроллер доступа при аутентификации, таким образом, сервер аутентификации, которому доверяет контроллер доступа при аутентификации, определяет сервер аутентификации, которому доверяет инициатор запроса, в соответствии с ID_{AS_REQ}.

[00383] Следует отметить, что в этом варианте осуществления результатом указанного определения является случай наличия роуминга.

[00384] На этапе S906 контроллер доступа при аутентификации отправляет AACVeri на сервер аутентификации, которому доверяет контроллер доступа при аутентификации.

[00385] AACVeri включает в себя EncPub_{AS_REQ}, Nonce_REQ, EncPub_{AS_AAC}, Nonce_AAC и ID_{AS_REQ}. Поле «ID_ASREQ» является необязательным; а EncPub_{AS_REQ}, Nonce_REQ и ID_{AS_REQ}, соответственно, должны быть идентичными имеющимся в соответствующих полях в REQInit. Подлежащие шифрованию данные EncPub_{AS_AAC} включают в себя ID_AAC, Cert_AAC, Nonce_AACID и Nonce_AACPub.

[00386] На этапе S907 после приема AACVeri сервер аутентификации, которому доверяет контроллер доступа при аутентификации, отправляет первое сообщение AS-AACReq с запросом расшифровки на сервер сертификатов для расшифровки (Certificate Sever-Decrypt, CS-DEC).

[00387] AS-AACReq включает в себя EncPub_{AS_AAC}.

[00388] На этапе S908 после приема AS-AACReq сервер сертификатов для расшифровки расшифровывает EncPub_{AS_AAC}, чтобы получить ID_AAC, Cer_tAAC, Nonce_AACID и Nonce_AACPub.

[00389] На этапе S909 сервер сертификатов для расшифровки отправляет первое ответное сообщение CS-DECRep расшифровки на сервер аутентификации, которому доверяет контроллер доступа при аутентификации.

[00390] CS-DECRep включает в себя ID_AAC, Cert_AAC, Nonce_AACID и Nonce_AACPub, которые получены путем расшифровки.

[00391] На этапе S910 после приема CS-DECRep сервер аутентификации, которому доверяет контроллер доступа при аутентификации, выполняет следующие операции.

[00392] (1) Верифицирует легитимность Cert_AAC для получения Res_AAC и генерирует Pub_AAC в соответствии с информацией, включающей в себя Cert_AAC и Res_AAC.

[00393] (2) В отношении Nonce_AACPub и Pub_AAC выполняет операцию «исключающего или», чтобы сгенерировать Pub_AAC⊕Nonce_AACPub.

[00394] (3) В отношении Nonce_AACID и ID_AAC выполняет операцию «исключающего или», чтобы сгенерировать ID_AAC⊕Nonce_AACID.

[00395] (4) Если ID_{AS_REQ} содержится в AACVeri, сервер аутентификации, которому доверяет контроллер доступа при аутентификации, определяет сервер аутентификации, которому доверяет инициатор запроса, в соответствии с ID_{AS_REQ}; а если это не так, это указывает на то, что сервер аутентификации, которому доверяет инициатор запроса, был известен серверу аутентификации, которому доверяет контроллер доступа при аутентификации.

[00396] (5) Вычисляет Sig_{AS_AAC3}.

[00397] На этапе S911 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, отправляет сигнал AS-AACVeri на сервер аутентификации, которому доверяет инициатор запроса.

[00398] AS-AACVeri включает в себя EncPub_{AS_REQ}, Nonce_REQ, Nonce_AAC, Pub_AAC⊕Nonce_AACPub, ID_AAC⊕Nonce_AACID и Sig_{AS_AAC3}. Подлежащие подписанию данные Sig_{AS_AAC3} включают в себя другие поля перед Sig_{AS_AAC3} в AS-AACVeri; Nonce_REQ, Nonce_AAC и EncPub_{AS_REQ}, соответственно, должны быть идентичными имеющимся в соответствующих полях в AACVeri; а Nonce_REQ, Nonce_AACPub ID_AAC и Nonc_eAACID, соответственно, должны быть идентичными имеющимся в соответствующих полях в CS-DECRep.

[00399] На этапе S912 после приема AS-AACVeri сервер аутентификации, которому доверяет инициатор запроса, верифицирует Sig_{AS_AAC3} путем использования открытого ключа сервера аутентификации, которому доверяет контроллер доступа при аутентификации.

[00400] Если верификация успешна, выполняется этап S913.

[00401] На этапе S913 сервер аутентификации, которому доверяет инициатор запроса, отправляет второе сообщение AS-REQReq с запросом расшифровки на сервер сертификатов для расшифровки.

[00402] AS-REQReq включает в себя EncPub_{AS_REQ}; а EncPub_{AS_REQ} должен быть идентичным имеющемуся в соответствующем поле в AS-AACVeri.

[00403] На этапе S914 сервер сертификатов для расшифровки расшифровывает EncPub_{AS_REQ}, чтобы получить Cert_REQ, ID_REQ, Nonce_REQID и Nonce_REQPub.

[00404] На этапе S915 сервер сертификатов для расшифровки отправляет второе ответное сообщение CS-DECRep расшифровки на сервер аутентификации, которому доверяет инициатор запроса.

[00405] CS-DECRep включает в себя ID_REQ, Cert_AAC, Nonce_REQID и Nonce_REQPub, которые получены путем расшифровки.

[00406] На этапе S916 после приема CS-DECRep сервер аутентификации, которому доверяет инициатор запроса, выполняет следующие операции.

[00407] (1) Верифицирует легитимность Cert_REQ для получения Res_REQ и генерирует Pub_REQ в соответствии с информацией, включающей в себя Cert_REQ и Res_REQ.

[00408] (2) В отношении Pub_REQ и Nonce_REQPub выполняет операцию «исключающего или», чтобы сгенерировать Pub_REQ⊕Nonce_REQPub.

[00409] (3) В отношении ID_REQ и Nonce_REQID выполняет операцию «исключающего или», чтобы сгенерировать ID_REQ⊕Nonce_REQID.

[00410] (4) Вычисляет Sig_{AS_REQ1} и Sig_{AS_REQ4}.

[00411] На этапе S917 сервер аутентификации, которому доверяет инициатор запроса, отправляет сигнал AS-REQVeri на сервер аутентификации, которому доверяет контроллер доступа при аутентификации.

[00412] AS-REQVeri включает в себя ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub, Sig_{AS_REQ1}, ID_AAC⊕Nonce_AACID, Nonce_AAC, Pub_REQ⊕Nonce_REQPub и Sig_{AS_REQ4}. ID_REQ, Nonce_REQID и Nonce_REQPub, соответственно, должны быть идентичными имеющимся в соответствующих полях в CS-DECRep; а Nonce_REQ, ID_AAC⊕Nonce_AACID, Nonce_AAC и Pub_AAC⊕Nonce_AACPub, соответственно, должны быть идентичными имеющимся в соответствующих полях в AS-AACVeri. Подлежащие подписанию данные Sig_{AS_REQ1} включают в себя ID_REQ⊕Nonce_REQID, Nonce_REQ и Pub_AAC⊕Nonce_AACPub; а подлежащие подписанию данные Sig_{AS_REQ4} включают в себя ID_AAC⊕Nonce_AACID, Nonce_AAC и Pub_REQ⊕Nonce_REQPub.

[00413] На этапе S918 после приема AS-REQVeri сервер аутентификации, которому доверяет контроллер доступа при аутентификации, выполняет следующие операции.

[00414] (1) Верифицирует Sig_{AS_REQ4} путем использования открытого ключа сервера аутентификации, которому доверяет инициатор запроса; если верификация не была успешной, AS-REQVeri отбрасывается.

[00415] (2) Вычисляет Sig_{AS_AAC2}.

[00416] На этапе S919 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, отправляет сигнал ASVeri на контроллер доступа при аутентификации.

[00417] ASVeri включает в себя ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub, Sig_{AS_REQ1}, ID_AAC⊕Nonce_AACID, Nonce_AAC, Pub_REQ⊕Nonce_REQPub и Sig_{AS_AAC2}. ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub, Sig_{AS_REQ1}, ID_AAC⊕Nonce_AACID, Nonce_AAC и Pub_REQ⊕Nonce_REQPub, соответственно, должны быть идентичными имеющимся в соответствующих полях в AS-REQVeri. Подлежащие подписанию данные Sig_{AS_AAC2} включают в себя ID_AAC⊕Nonce_AACID, Nonce_AAC и Pub_REQ⊕Nonce_REQPub.

[00418] На этапе S920 после приема ASVeri контроллер доступа при аутентификации выполняет следующие операции.

[00419] (1) В отношении Nonce_AACID и ID_AAC⊕Nonce_AACID выполняет операцию «исключающего или», чтобы восстановить ID_AAC, и выполняет проверку того, является ли ID_AAC таким же, как собственный ID_AAC контроллера доступа при аутентификации.

[00420] (2) Выполняет проверку того, является ли Nonce_AAC таким же, как Nonce_AAC, сгенерированное контроллером доступа при аутентификации.

[00421] (3) Верифицирует Sig_{AS_AAC2} путем использования открытого ключа сервера аутентификации, которому доверяет контроллер доступа при аутентификации.

[00422] (4) Если проверка и верификация успешны, вычисляет EncData_AAC путем использования ключа шифрования сообщения; и если какой-либо из этапов проверки и верификации не был успешным, немедленно отбрасывает ASVeri.

[00423] (5) Вычисляет Sig_AAC.

[00424] (6) Вычисляет MacTag_AAC в соответствии с требованиями.

[00425] На этапе S921 контроллер доступа при аутентификации отправляет третье ответное сообщение AACAuth об аутентификации на инициатор запроса.

[00426] AACAuth включает в себя Nonce_REQ, Nonce_AAC, EncData_AAC, Sig_AAC и MacTag_AAC. Поля «Nonce_REQ», «Nonce_AAC» и «MacTag_AAC» являются необязательными; а Nonce_REQ и Nonce_AAC, соответственно, должны быть идентичными Nonce_REQ в REQInit и Nonce_AAC, сгенерированному контроллером доступа при аутентификации. Подлежащие шифрованию данные EncData_AAC включают в себя ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub, Sig_{AS_REQ1} и Nonce_AACPub; а ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub и Sig_{AS_REQ1}, соответственно, должны быть идентичными имеющимся в соответствующих полях в ASVeri. Подлежащие подписанию данные Sig_AAC включают в себя другие поля перед Sig_AAC в AACAuth; и процесс вычисления MacTag_AAC описан в варианте осуществления по фиг. 7.

[00427] На этапе S922 после приема AACAuth инициатор запроса выполняет следующие операции.

[00428] (1) Если в AACAuth содержится Nonce_REQ и/или Nonce_AAC, выполняет проверку того, является ли Nonce_REQ таким же, как Nonce_REQ, сгенерированное инициатором запроса; и/или выполняет проверку того, является ли Nonce_AAC таким же, как принятое Nonce_AAC в AACInit.

[00429] (2) Если в AACAuth содержится MacTag_AAC, выполняет верификацию MacTag_AAC; и процесс верификации описан в варианте осуществления по фиг. 7.

[00430] (3) Использует для расшифровки EncData_AAC ключ шифрования сообщения путем использования алгоритма симметричного шифрования, чтобы получить ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub, Sig_{AS_REQ1} и Nonce_AACPub.

[00431] (4) В отношении ID_REQ⊕Nonce_REQID выполняет операцию «исключающего или» путем использования Nonce_REQID, чтобы восстановить ID_REQ, и выполняет проверку того, является ли ID_REQ таким же, как собственный ID_REQ инициатора запроса.

[00432] (5) Выполняет проверку того, является ли Nonce_REQ таким же, как Nonce_REQ, сгенерированное инициатором запроса.

[00433] (6) В отношении Nonce_AACPub и Pub_AAC⊕Nonce_AACPub, полученных путем расшифровки, выполняет операцию «исключающего или», чтобы восстановить Pub_AAC.

[00434] (7) Верифицирует Sig_{AS_REQ1} путем использования открытого ключа сервера аутентификации, которому доверяет инициатор запроса, и верифицирует Sig_AAC путем использования Cert_AAC в Pub_AAC.

[00435] (8) Если какой-либо из этапов проверки и верификации не был успешным, немедленно отбрасывает AACAuth; если проверка и верификация успешны, определяет результат аутентификации идентификационной информации контроллера доступа при аутентификации в соответствии с ResAAC в PubAAC; и если определяет, что контроллер доступа при аутентификации нелегитимен, завершает текущий процесс аутентификации.

[00436] (9) Использует ключ шифрования сообщения для вычисления EncData_REQ.

[00437] (10) Вычисляет MacTag_REQ.

[00438] На этапе S923 инициатор запроса отправляет четвертое ответное сообщение REQAuth об аутентификации на контроллер доступа при аутентификации.

[00439] AACAuth включает в себя Nonce_AAC, Nonce_REQ, EncData_REQ и MacTag_REQ. Поля «Nonce_REQ» и «Nonce_AAC» являются необязательными; и, соответственно, должны быть идентичными Nonce_REQ, сгенерированному инициатором запроса, и Nonce_AAC в AACInit. Подлежащие шифрованию данные EncData_REQ включают в себя Nonce_REQPub. Процесс вычисления MacTag_REQ описан в варианте осуществления по фиг. 7.

[00440] На этапе S924 после приема REQAuth контроллер доступа при аутентификации выполняет следующие операции.

[00441] (1) Если в REQAuth содержится Nonce_REQ и/или Nonce_AAC, выполняет проверку того, является ли Nonce_REQ таким же, как Nonce_REQ в REQInit; и/или выполняет проверку того, является ли Nonce_AAC таким же, как Nonce_AAC, сгенерированное контроллером доступа при аутентификации.

[00442] (2) Верифицирует MacTag_REQ; и процесс верификации описан в варианте осуществления по фиг. 7.

[00443] (3) Использует ключ шифрования сообщения для расшифровки EncData_REQ путем использования алгоритма симметричного шифрования, чтобы получить Nonce_REQPub.

[00444] (4) В отношении Nonce_REQPub и Pub_REQ⊕Nonce_REQPub выполняет операцию «исключающего или», чтобы восстановить Pub_REQ.

[00445] (5) Верифицирует Sig_REQ в REQInit путем использования Cert_REQ в Pub_REQ.

[00446] (6) После успешной проверки и верификации определяет результат аутентификации идентификационной информации инициатора запроса в соответствии с Res_REQ в Pub_REQ; и если какой-либо один из этапов проверки и верификации не был успешным, немедленно отбрасывает REQAuth.

[00447] Следует отметить, что REQInit на этапе S904 может не включать в себя Sig_REQ, но при этом Sig_REQ добавлен в REQAuth на этапе S923. Другими словами, на этапе S923 инициатор запроса сначала генерирует Sig_REQ путем выполнения вычисления по подлежащим подписанию данным, включающим в себя Nonce_AAC, Nonce_REQ и EncData_REQ. В этом случае Sig_REQ, верифицированная контроллером доступа при аутентификации на этапе S924, представляет собой Sig_REQ в REQAuth на этапе S923.

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

[00449] На этапе S1001 контроллер доступа при аутентификации генерирует Nonce_AAC и KeyInfo_AAC, и генерирует средства безопасности_AAC в соответствии с требованиями.

[00450] На этапе S1002 контроллер доступа при аутентификации отправляет AACInit на инициатор запроса.

[00451] AACInit включает в себя Nonce_AAC, KeyInfo_AAC, ID_{AS_AAC} и средства безопасности_AAC. Поля «средства безопасности_AAC» и «ID_{AS_AAC}» являются необязательными.

[00452] На этапе S1003 инициатор запроса генерирует Nonce_REQ, KeyInfo_REQ, Nonce_REQID и Nonce_REQPub, генерирует ID_{AS_REQ} и средства безопасности_REQ в соответствии с требованиями и выполняет вычисление обмена ключами в соответствии с временным закрытым ключом, соответствующим KeyInfo_REQ, и временным открытым ключом, включенным в KeyInfo_AAC, чтобы сгенерировать первый ключ K1; причем K1 объединяют с Nonce_AAC, Nonce_REQ и другой информацией (другая информация, используемая инициатором запроса и контроллером доступа при аутентификации, является одинаковой и необязательной, например, определенная строка), чтобы вычислить ключ шифрования сообщения и ключ проверки целостности сообщения путем использования согласованного или заранее заданного алгоритма формирования ключа, конечно, этот этап также может быть выполнен, когда ключ проверки целостности сообщения и/или ключ проверки целостности сообщения необходимо использовать позже; открытый ключ сертификата шифрования используют для вычисления EncPub_{AS_REQ} инициатора запроса; и вычисляют Sig_REQ.

[00453] На этапе S1004 инициатор запроса отправляет REQInit на контроллер доступа при аутентификации.

[00454] REQInit включает в себя Nonce_AAC, Nonce_REQ, ID_{AS_REQ}, средства безопасности_REQ, KeyInfo_REQ, EncPub_{AS_REQ} и Sig_REQ. Поля «ID_{AS_REQ}» и «средства безопасности_REQ» являются необязательными; а Nonce_AAC должно быть идентичным имеющемуся в соответствующем поле в AACInit; и подлежащие шифрованию данные EncPub_{AS_REQ} включают в себя ID_REQ, Cert_REQ, Nonce_REQID и Nonce_REQPub. Подлежащие подписанию данные Sig_REQ включают в себя другие поля перед Sig_REQ в REQInit.

[00455] На этапе S1005 после приема REQInit контроллер доступа при аутентификации выполняет следующие операции.

[00456] (1) Выполняет проверку того, является ли Nonce_AAC в REQInit таким же, как Nonce_AAC, сгенерированное контроллером доступа при аутентификации; и если это не так, отбрасывает REQInit.

[00457] (2) Выполняет вычисление обмена ключами в соответствии с временным закрытым ключом, соответствующим KeyInfo_AAC, и временным открытым ключом, включенным в KeyInfo_REQ, чтобы сгенерировать первый ключ K1; причем K1 объединяют с Nonce_AAC, Nonce_REQ и другой информацией (другая информация, используемая инициатором запроса и контроллером доступа при аутентификации, является одинаковой и необязательной, например, определенная строка), чтобы вычислить ключ шифрования сообщения и ключ проверки целостности сообщения путем использования согласованного или заранее заданного алгоритма формирования ключа. Конечно, этот этап может быть выполнен, когда ключ проверки целостности сообщения и/или ключ проверки целостности сообщения должны использоваться контроллером доступа при аутентификации.

[00458] (3) Генерирует Nonce_AACID и Nonce_AACPub.

[00459] (4) Использует открытый ключ сертификата шифрования для вычисления EncPub_{AS_AAC}.

[00460] (5) Способ для определения контроллером доступа при аутентификации сервера аутентификации, которому доверяет контроллер доступа при аутентификации, описан в варианте осуществления по фиг. 9.

[00461] (6) Вычисляет Sig_AAC.

[00462] На этапе S1006 контроллер доступа при аутентификации отправляет AACVeri на сервер аутентификации, которому доверяет контроллер доступа при аутентификации.

[00463] AACVeri включает в себя REQInit, EncPub_{AS_AAC} и Sig_AAC. Подлежащие шифрованию данные EncPub_{AS_AAC} включают в себя ID_AAC, Cert_AAC, Nonce_AACID и Nonce_AACPub. Подлежащие подписанию данные Sig_AAC включают в себя другие поля перед Sig_AAC в AACVeri.

[00464] На этапе S1007 после приема AACVeri сервер аутентификации, которому доверяет контроллер доступа при аутентификации, отправляет AS-AACReq на сервер сертификатов для расшифровки.

[00465] AS-AACReq включает в себя EncPub_{AS_AAC}; и EncPub_{AS_AAC} должен быть идентичным имеющемуся в соответствующем поле в AACVeri.

[00466] На этапе S1008 после приема AS-AACReq сервер сертификатов для расшифровки расшифровывает EncPub_{AS_AAC}, чтобы получить ID_AAC, Cert_AAC, Nonce_AACID и Nonce_AACPub.

[00467] На этапе S1009 сервер сертификатов для расшифровки отправляет первое ответное сообщение CS-DECRep расшифровки на сервер аутентификации, которому доверяет контроллер доступа при аутентификации.

[00468] CS-DECRep включает в себя ID_AAC, Cert_AAC, Nonce_AACID и Nonce_AACPub, которые получены путем расшифровки.

[00469] На этапе S1010 после приема CS-DECRep сервер аутентификации, которому доверяет контроллер доступа при аутентификации, выполняет следующие операции.

[00470] (1) Верифицирует Sig_AAC путем использования Cert_AAC; и, если верификация не была успешной, отбрасывает CS-DECRep.

[00471] (2) Верифицирует легитимность Cert_AAC для получения Res_AAC и генерирует Pub_AAC в соответствии с информацией, включающей в себя Res_AAC.

[00472] (3) В отношении Nonce_AACPub и Pub_AAC выполняет операцию «исключающего или», чтобы получить Pub_AAC Nonce_AACPub.

[00473] (4) В отношении Nonce_AACID и ID_AAC выполняет операцию «исключающего или», чтобы получить ID_AAC Nonce_AACID.

[00474] (5) Способ определения сервером аутентификации, которому доверяет контроллер доступа при аутентификации, сервера аутентификации, которому доверяет инициатор запроса, описан в варианте осуществления по фиг. 9.

[00475] (6) Вычисляет Sig_{AS_AAC3}.

[00476] На этапе S1011 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, отправляет сигнал AS-AACVeri на сервер аутентификации, которому доверяет инициатор запроса.

[00477] AS-AACVeri включает в себя REQInit, Pub_AAC⊕Nonce_AACPub, ID_AAC⊕Nonce_AACID и Sig_{AS_AAC3}. Nonce_AACPub, ID_AAC и Nonce_AACID, соответственно, должны быть идентичными имеющимся в соответствующих полях в CS-DECRep. Подлежащие подписанию данные Sig_{AS_AAC3} включают в себя другие поля перед Sig_{AS_AAC3} в AS-AACVeri.

[00478] На этапе S1012 после приема AS-AACVeri сервер аутентификации, которому доверяет инициатор запроса, верифицирует Sig_{AS_AAC3} путем использования открытого ключа сервера аутентификации, которому доверяет контроллер доступа при аутентификации.

[00479] Если верификация успешна, выполняется этап S1013.

[00480] На этапе S1013 сервер аутентификации, которому доверяет инициатор запроса, отправляет второе сообщение AS-REQReq с запросом расшифровки на сервер сертификатов для расшифровки.

[00481] AS-REQReq включает в себя EncPub_{AS_REQ}; а EncPub_{AS_REQ} должен быть идентичным имеющемуся в соответствующем поле в AS-AACVeri.

[00482] На этапе S1014 сервер сертификатов для расшифровки расшифровывает EncPub_{AS_REQ}, чтобы получить Cert_REQ, ID_REQ, Nonce_REQID и Nonce_REQPub.

[00483] На этапе S1015 сервер сертификатов для расшифровки отправляет второе ответное сообщение CS-DECRep расшифровки на сервер аутентификации, которому доверяет инициатор запроса.

[00484] CS-DECRep включает в себя ID_REQ, Cert_AAC, Nonce_REQID и Nonce_REQPub, которые получены путем расшифровки.

[00485] На этапе S1016 после приема CS-DECRep сервер аутентификации, которому доверяет инициатор запроса, выполняет следующие операции.

[00486] (1) Верифицирует Sig_REQ в REQInit путем использования Cert_REQ; и, если верификация не была успешной, отбрасывает CS-DECRep.

[00487] (2) Верифицирует легитимность Cert_REQ для получения Res_REQ и генерирует Pub_REQ в соответствии с информацией, включающей в себя Res_REQ.

[00488] (3) В отношении Nonce_REQPub и Pub_REQ выполняет операцию «исключающего или», чтобы получить Pub_REQ Nonce_REQPub.

[00489] (4) В отношении Nonce_REQID и ID_REQ выполняет операцию «исключающего или», чтобы получить ID_REQ Nonce_REQID.

[00490] (5) Вычисляет Sig_{AS_REQ1} и Sig_{AS_REQ4}.

[00491] На этапе S1017 сервер аутентификации, которому доверяет инициатор запроса, отправляет сигнал AS-REQVeri на сервер аутентификации, которому доверяет контроллер доступа при аутентификации.

[00492] AS-REQVeri включает в себя ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub, Sig_{AS_REQ1}, ID_AAC⊕Nonce_AACID, Nonce_AAC, Pub_REQ Nonce_REQPub и Sig_{AS_REQ4}. ID_REQ, Nonce_REQID и Nonce_REQPub, соответственно, должны быть идентичными имеющимся в соответствующих полях в CS-DECRep; а Nonce_REQ, ID_AAC⊕Nonce_AACID, Nonce_AAC и Pub_AAC⊕Nonce_AACPub, соответственно, должны быть идентичными имеющимся в соответствующих полях в AS-AACVeri. Подлежащие подписанию данные Sig_{AS_REQ1} включают в себя ID_REQ⊕Nonce_REQID, Nonce_REQ и Pub_AAC⊕Nonce_AACPub; а подлежащие подписанию данные Sig_{AS_REQ4} включают в себя ID_AAC⊕Nonce_AACID, Nonce_AAC и Pub_REQ⊕Nonce_REQPub.

[00493] На этапе S1018 после приема AS-REQVeri сервер аутентификации, которому доверяет контроллер доступа при аутентификации, выполняет следующие операции.

[00494] (1) Верифицирует Sig_{AS_REQ4} путем использования открытого ключа сервера аутентификации, которому доверяет инициатор запроса; если верификация не была успешной, AS-REQVeri отбрасывается.

[00495] (2) Вычисляет Sig_{AS_AAC2}.

[00496] На этапе S1019 сервер аутентификации, которому доверяет контроллер доступа при аутентификации, отправляет сигнал ASVeri на контроллер доступа при аутентификации.

[00497] ASVeri включает в себя ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub, Sig_{AS_REQ1}, ID_AAC⊕Nonce_AACID, Nonce_AAC, Pub_REQ⊕Nonce_REQPub и Sig_{AS_AAC2}. Подлежащие подписанию данные Sig_{AS_AAC2} включают в себя ID_AAC⊕Nonce_AACID, Nonce_AAC и Pub_REQ⊕Nonce_REQPub.

[00498] На этапе S1020 после приема ASVeri контроллер доступа при аутентификации выполняет следующие операции.

[00499] (1) В отношении Nonce_AACID и ID_AAC⊕Nonce_AACID выполняет операцию «исключающего или», чтобы восстановить ID_AAC, и выполняет проверку того, является ли ID_AAC таким же, как собственный ID_AAC контроллера доступа при аутентификации.

[00500] (2) Выполняет проверку того, является ли Nonce_AAC таким же, как Nonce_AAC, сгенерированное контроллером доступа при аутентификации.

[00501] (3) Верифицирует Sig_{AS_AAC2} путем использования открытого ключа сервера аутентификации, которому доверяет контроллер доступа при аутентификации.

[00502] (4) Если проверка и верификация успешны, вычисляет EncData_AAC путем использования ключа шифрования сообщения; и если какой-либо из этапов проверки и верификации не был успешным, немедленно отбрасывает ASVeri.

[00503] (5) Вычисляет MacTag_AAC.

[00504] На этапе S1021 контроллер доступа при аутентификации отправляет третье ответное сообщение AACAuth об аутентификации на инициатор запроса.

[00505] AACAuth включает в себя Nonce_REQ, Nonce_AAC, EncData_AAC и MacTag_AAC. Поля «Nonce_REQ» и «Nonce_AAC» являются необязательными; и, соответственно, должны быть идентичными Nonce_REQ в REQInit, сгенерированному инициатором запроса, и Nonce_AAC, сгенерированному контроллером доступа при аутентификации. Подлежащие шифрованию данные EncData_AAC включают в себя ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub, Sig_{AS_REQ1} и Nonce_AACPub; а ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub и Sig_{AS_REQ1}, соответственно, должны быть идентичными имеющимся в соответствующих полях в ASVeri. Процесс вычисления MacTag_AAC описан в варианте осуществления по фиг. 7.

[00506] На этапе S1022 после приема AACAuth инициатор запроса выполняет следующие операции.

[00507] (1) Если в AACAuth содержится Nonce_REQ и/или Nonce_AAC, выполняет проверку того, является ли Nonce_REQ таким же, как Nonce_REQ, сгенерированное инициатором запроса; и/или выполняет проверку того, является ли Nonce_AAC таким же, как принятое Nonce_AAC в AACInit.

[00508] (2) Верифицирует MacTag_AAC; процесс верификации описан в варианте осуществления по фиг. 7.

[00509] (3) Использует для расшифровки EncData_AAC ключ шифрования сообщения путем использования алгоритма симметричного шифрования, чтобы получить ID_REQ⊕Nonce_REQID, Nonce_REQ, Pub_AAC⊕Nonce_AACPub, Sig_{AS_REQ1} и Nonce_AACPub.

[00510] (4) В отношении ID_REQ⊕Nonce_REQID выполняет операцию «исключающего или» путем использования Nonce_REQID, чтобы восстановить ID_REQ, и выполняет проверку того, является ли ID_REQ таким же, как собственный ID_REQ инициатора запроса.

[00511] (5) Выполняет проверку того, является ли Nonce_REQ таким же, как Nonce_REQ, сгенерированное инициатором запроса.

[00512] (6) Верифицирует Sig_{AS_REQ1} путем использования открытого ключа сервера аутентификации, которому доверяет инициатор запроса.

[00513] (7) Если какой-либо из этапов проверки и верификации не был успешным, немедленно отбрасывает AACAuth; если проверка и верификация успешны, в отношении Nonce_AACPub и Pub_AAC⊕Nonce_AACPub, полученных путем расшифровки, выполняет операцию «исключающего или», чтобы восстановить PubAAC; определяет результат аутентификации идентификационной информации контроллера доступа при аутентификации в соответствии с ResAAC в PubAAC; и если определяет, что контроллер доступа при аутентификации нелегитимен, завершает текущий процесс аутентификации.

[00514] (8) Использует ключ шифрования сообщения для вычисления EncData_REQ.

[00515] (9) Вычисляет MacTag_REQ.

[00516] На этапе S1023 инициатор запроса отправляет четвертое ответное сообщение REQAuth об аутентификации на контроллер доступа при аутентификации.

[00517] REQAuth включает в себя Nonce_AAC, Nonce_REQ, EncData_REQ и MacTag_REQ. Поля «Nonce_REQ» и «Nonce_AAC» являются необязательными; и, соответственно, должны быть идентичными Nonce_REQ, сгенерированному инициатором запроса, и Nonce_AAC в AACInit. Подлежащие шифрованию данные EncData_REQ включают в себя Nonce_REQPub. Процесс вычисления MacTag_REQ описан в варианте осуществления по фиг. 7.

[00518] На этапе S1024 после приема REQAuth контроллер доступа при аутентификации выполняет следующие операции.

[00519] (1) Если в REQAuth содержится Nonce_REQ и/или Nonce_AAC, выполняет проверку того, является ли Nonce_REQ таким же, как Nonce_REQ в REQInit; и/или выполняет проверку того, является ли Nonce_AAC таким же, как Nonce_AAC, сгенерированное контроллером доступа при аутентификации.

[00520] (2) Верифицирует MacTag_REQ; и процесс верификации описан в варианте осуществления по фиг. 7.

[00521] (3) Использует ключ шифрования сообщения для расшифровки EncData_REQ путем использования алгоритма симметричного шифрования, чтобы получить Nonce_REQPub.

[00522] (4) В отношении Nonce_REQPub и Pub_REQ⊕Nonce_REQPub выполняет операцию «исключающего или», чтобы восстановить Pub_REQ.

[00523] (5) После успешной проверки и верификации определяет результат аутентификации идентификационной информации инициатора запроса в соответствии с Res_REQ в Pub_REQ; и если какой-либо один из этапов проверки и верификации не был успешным, немедленно отбрасывает REQAuth.

[00524] В приведенных выше вариантах осуществления каждое сообщение может дополнительно содержать хеш-значение HASH_{X_Y}; и хеш-значение HASH_{X_Y} получают путем использования объектом-отправителем X сообщения хеш-алгоритма для вычисления принятого последнего предшествующего сообщения, отправленного объектом Y на противоположном конце, и используют для объекта Y на противоположном конце для верификации того, принял ли объект X все последнее предшествующее сообщение. HASH_{REQ_AAC} представляет собой хеш-значение, вычисленное инициатором запроса для принятого последнего предшествующего сообщения, отправленного контроллером доступа при аутентификации; HASH_{AAC_REQ} представляет собой хеш-значение, вычисленное контроллером доступа при аутентификации для принятого последнего предшествующего сообщения, отправленного инициатором запроса; HASHAAC_AS-AAC представляет собой хеш-значение, вычисленное контроллером доступа при аутентификации для принятого последнего предшествующего сообщения, отправленного сервером аутентификации, которому доверяет контроллер доступа при аутентификации; HASHAS-AAC_AAC представляет собой хеш-значение, вычисленное сервером аутентификации, которому доверяет контроллер доступа при аутентификации, для принятого последнего предшествующего сообщения, отправленного контроллером доступа при аутентификации; HASH_{AS-AAC_AS-REQ} представляет собой хеш-значение, вычисленное сервером аутентификации, которому доверяет контроллер доступа при аутентификации, для принятого последнего предшествующего сообщения, отправленного сервером аутентификации, которому доверяет инициатор запроса; и HASH_{AS-REQ_AS-AAC} представляет собой хеш-значение, вычисленное сервером аутентификации, которому доверяет инициатор запроса, для принятого последнего предшествующего сообщения, отправленного сервером аутентификации, которому доверяет контроллер доступа при аутентификации. Если сообщение, отправленное в настоящий момент объектом-отправителем X, является первым сообщением взаимодействия между объектом X и объектом Y, это означает, что объект X не принял предшествующее сообщение, отправленное объектом Y на противоположном конце, и HASH_{X_Y} в сообщении может отсутствовать или не иметь смысла.

[00525] Соответственно, после того как объект Y на противоположном конце принял сообщение, отправленное объектом X, если сообщение включает в себя HASH_{X_Y}, объект Y игнорирует HASH_{X_Y}, если объект Y не отправлял предшествующее сообщение объекту X; когда объект Y отправлял предшествующее сообщение объекту X, объект Y использует хеш-алгоритм для локального вычисления хеш-значения для последнего предшествующего сообщения, отправленного объекту X, и сравнивает хеш-значение с принятым значением HASH_{X_Y}, содержащимся в сообщении; и если хеш-значение соответствует HASH_{X_Y}, выполняются последующие этапы, в противном случае выполняется отбрасывание или текущий процесс аутентификации завершается.

[00526] В настоящем изобретении для объекта X предшествующее сообщение, отправленное объекту X объектом Y на противоположном конце, относится к принятому сообщению, которое отправлено объекту X объектом Y на противоположном конце до того, как объект X отправит сообщение M объекту Y на противоположном конце; и последнее предшествующее сообщение, отправленное объекту X объектом Y на противоположном конце, относится к принятому последнему сообщению, которое отправлено объекту X объектом Y на противоположном конце до того, как объект X отправит сообщение M объекту Y на противоположном конце. Если сообщение M, отправленное объектом X объекту Y на противоположном конце, является первым сообщением взаимодействия между объектом X и объектом Y; и до того, как объект X отправит сообщение M объекту Y на противоположном конце, предшествующее сообщение, отправленное объектом Y на противоположном конце объекту X, не существует.

[00527] Необязательные поля и необязательные операции в соответствующих вариантах осуществления по фиг. 7, фиг. 8, фиг. 9 и фиг. 10 представлены знаком «*» на фиг. 7, фиг. 8, фиг. 9 и фиг. 10 чертежей к описанию. Последовательность содержимого, включенного в сообщения, включенные во все из вышеупомянутых вариантов осуществления, не ограничена. Кроме того, последовательность операций с соответствующими сообщениями после того, как получатель сообщения принял сообщение, и последовательность, в которой обрабатывается содержимое, включенное в сообщения, не ограничены, если не указано иное.

[00528] На основании вариантов осуществления способа, соответствующих фиг. с 1 по 10, со ссылкой на фиг. 11, в варианте осуществления настоящего раскрытия предложен контроллер доступа при аутентификации. Контроллер доступа при аутентификации включает в себя часть для получения, первую часть для отправки, первую часть для приема, первую часть для верификации, вторую часть для отправки, вторую часть для приема, часть для расшифровки и первую часть для определения.

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

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

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

[00532] Первая часть 1104 для верификации выполнена с возможностью верификации второй цифровой подписи путем использования открытого ключа первого сервера аутентификации.

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

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

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

[00536] Первая часть 1108 для определения выполнена с возможностью определения результата аутентификации идентификационной информации инициатора запроса в соответствии со вторым результатом верификации во второй информации о результате аутентификации.

[00537] В некоторых вариантах осуществления контроллер доступа при аутентификации дополнительно включает в себя третью часть для отправки и часть для вычисления.

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

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

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

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

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

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

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

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

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

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

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

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

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

[00551] Контроллер доступа при аутентификации дополнительно включает в себя третью часть для верификации.

[00552] Третья часть для верификации выполнена с возможностью верификации зашифрованного текста идентификационного идентификатора контроллера доступа при аутентификации в соответствии с идентификационным идентификатором контроллера доступа при аутентификации и четвертым одноразовым случайным защитным числом. После успешной верификации первая часть 1108 для определения затем выполняет соответствующие этапы.

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

[00554] В некоторых вариантах реализации первая часть 1108 для определения дополнительно выполнена с возможностью осуществления следующих операций.

[00555] Если вторая информация о результате аутентификации, полученная путем использования, частью 1107 для расшифровки, первого одноразового случайного защитного числа для расшифровки зашифрованного текста второй информации о результате аутентификации, дополнительно включает в себя цифровой сертификат инициатора запроса, первая часть 1108 для определения верифицирует цифровую подпись инициатора запроса путем использования цифрового сертификата инициатора запроса и определяет, в соответствии с результатом верификации, успешна ли верификация цифровой подписи инициатора запроса.

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

[00557] В некоторых вариантах реализации четвертое ответное сообщение об аутентификации, принятое второй частью 1106 для приема, дополнительно включает в себя цифровую подпись инициатора запроса; вторая информация о результате аутентификации, полученная путем использования, частью 1107 для расшифровки, первого одноразового случайного защитного числа для расшифровки зашифрованного текста второй информации о результате аутентификации, дополнительно включает в себя цифровой сертификат инициатора запроса; и перед определением результата аутентификации идентификационной информации инициатора запроса первая часть 1108 для определения дополнительно выполнена с возможностью верификации цифровой подписи инициатора запроса путем использования цифрового сертификата инициатора запроса в первой информации о результате аутентификации, и если определено, что верификация цифровой подписи инициатора запроса успешна, то определяют результат аутентификации идентификационной информации инициатора запроса в соответствии со вторым результатом верификации.

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

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

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

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

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

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

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

[00565] Первая часть 1204 для верификации выполнена с возможностью верификации первой цифровой подписи путем использования открытого ключа второго сервера аутентификации, причем, если верификация успешна, первая часть 1203 для расшифровки расшифровывает зашифрованный текст первой информации о результате аутентификации путем использования второго одноразового случайного защитного числа, чтобы получить первую информацию о результате аутентификации, первая часть 1205 для определения определяет результат аутентификации идентификационной информации контроллера доступа при аутентификации в соответствии с первым результатом верификации в первой информации о результате аутентификации и, когда первая часть 1205 для определения определяет, что результат аутентификации идентификационной информации контроллера доступа при аутентификации: «легитимен», вторая часть 1206 для отправки отправляет четвертое ответное сообщение об аутентификации на контроллер доступа при аутентификации.

[00566] Либо первая часть 1204 для верификации выполнена с возможностью верификации первой цифровой подписи путем использования открытого ключа второго сервера аутентификации. Если верификация успешна, вторая часть 1206 для отправки отправляет четвертое ответное сообщение об аутентификации на контроллер доступа при аутентификации, первая часть 1203 для расшифровки расшифровывает зашифрованный текст первой информации о результате аутентификации путем использования второго одноразового случайного защитного числа, чтобы получить первую информацию о результате аутентификации, и первая часть 1205 для определения определяет результат аутентификации идентификационной информации контроллера доступа при аутентификации в соответствии с первым результатом верификации в первой информации о результате аутентификации.

[00567] Либо первая часть 1204 для верификации выполнена с возможностью верификации первой цифровой подписи путем использования открытого ключа второго сервера аутентификации. Если верификация первой цифровой подписи успешна, первая часть 1203 для расшифровки расшифровывает зашифрованный текст первой информации о результате аутентификации путем использования второго одноразового случайного защитного числа, чтобы получить первую информацию о результате аутентификации, первая часть 1205 для определения определяет результат аутентификации идентификационной информации контроллера доступа при аутентификации в соответствии с первым результатом верификации в первой информации о результате аутентификации и вторая часть 1206 для отправки отправляет четвертое ответное сообщение об аутентификации на контроллер доступа при аутентификации.

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

[00569] В некоторых вариантах осуществления инициатор запроса дополнительно включает в себя вторую часть для приема и первую часть для вычисления.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[00588] Вторая часть для верификации выполнена с возможностью верификации зашифрованного текста идентификационного идентификатора инициатора запроса в соответствии с идентификационным идентификатором инициатора запроса и третьим одноразовым случайным защитным числом. После успешной верификации первая часть 1205 для определения затем выполняет этап определения результата аутентификации идентификационной информации контроллера доступа при аутентификации.

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

[00590] В некоторых вариантах реализации первая часть 1205 для определения дополнительно выполнена с возможностью осуществления следующих операций.

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

[00592] Либо, когда третье ответное сообщение об аутентификации, принятое первой частью 1202 для приема, дополнительно включает в себя цифровую подпись контроллера доступа при аутентификации, если первая информация о результате аутентификации, полученная путем расшифровки, первой частью 1203 для расшифровки, зашифрованного текста первой информации о результате аутентификации, дополнительно включает в себя цифровой сертификат контроллера доступа при аутентификации, первая часть 1205 для определения верифицирует цифровую подпись контроллера доступа при аутентификации путем использования цифрового сертификата контроллера доступа при аутентификации и определяет, в соответствии с результатом верификации, была ли успешной верификация цифровой подписи контроллера доступа при аутентификации.

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

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

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

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

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

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

[00599] В некоторых вариантах реализации первое сообщение с запросом аутентификации, принятое первой частью 1301 для приема, дополнительно включает в себя цифровую подпись контроллера доступа при аутентификации. Сервер аутентификации, которому доверяет контроллер доступа при аутентификации, дополнительно включает в себя первую часть для верификации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[00615] Часть 1401 для приема выполнена с возможностью приема второго сообщения с запросом аутентификации, отправленного первым сервером аутентификации. Второе сообщение с запросом аутентификации включает в себя зашифрованный текст первой информации о результате аутентификации, зашифрованный текст идентификационной информации инициатора запроса и третью цифровую подпись; и третья цифровая подпись представляет собой цифровую подпись, сгенерированную путем выполнения, сервером аутентификации, которому доверяет контроллер доступа при аутентификации, вычисления по подлежащим подписанию данным, включающим в себя зашифрованный текст первой информации о результате аутентификации и зашифрованный текст идентификационной информации инициатора запроса.

[00616] Первая часть 1402 для верификации выполнена с возможностью верификации третьей цифровой подписи путем использования открытого ключа первого сервера аутентификации.

[00617] Часть 1403 для получения выполнена с возможностью, когда верификация третьей цифровой подписи успешна, получения цифрового сертификата инициатора запроса и первого одноразового случайного защитного числа, которые получают путем использования закрытого ключа, соответствующего сертификату шифрования, для расшифровки зашифрованного текста идентификационной информации инициатора запроса.

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

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

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

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

[00622] На ФИГ. 15 представлена принципиальная структурная схема конструкции электронного устройства согласно варианту осуществления настоящего раскрытия. Как показано на фиг. 15, электронное устройство 1500 может представлять собой контроллер доступа при аутентификации, инициатор запроса, сервер аутентификации, которому доверяет контроллер доступа при аутентификации, или сервер аутентификации, которому доверяет инициатор запроса. Электронное устройство 1500 включает в себя процессор 1501 и запоминающее устройство 1502. Запоминающее устройство 1502 выполнено с возможностью хранения компьютерной программы. Процессор 1501 выполнен с возможностью вызова и запуска компьютерной программы, хранящейся в запоминающем устройстве 1502, для выполнения этапов в каком-либо из вышеприведенных вариантов осуществления, выполняемых контроллером доступа при аутентификации, инициатором запроса, сервером аутентификации, которому доверяет контроллер доступа при аутентификации, или сервером аутентификации, которому доверяет инициатор запроса. Процессор 1501 и запоминающее устройство 1502 электронного устройства 1500 могут, соответственно, представлять собой процессор 1501 и запоминающее устройство 1502 контроллера доступа при аутентификации, инициатора запроса, сервера аутентификации, которому доверяет контроллер доступа при аутентификации, или сервера аутентификации, которому доверяет инициатор запроса.

[00623] Ниже со ссылкой на фиг. 15 в качестве примера описаны, соответственно, контроллер доступа при аутентификации, инициатор запроса, сервер аутентификации, которому доверяет контроллер доступа при аутентификации, или сервер аутентификации, которому доверяет инициатор запроса.

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

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

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

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

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

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

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

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

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

[00633] На ФИГ. 16 представлена принципиальная структурная схема конструкции микросхемы согласно варианту осуществления настоящего раскрытия. Как показано на фиг. 16, микросхема 1600 включает в себя процессор 1601 и запоминающее устройство 1602. Процессор 1601 выполнен с возможностью вызова и запуска компьютерной программы из запоминающего устройства 1602, чтобы обеспечить возможность для контроллера доступа при аутентификации, в котором установлена микросхема 1600, осуществлять этапы, выполняемые контроллером доступа при аутентификации в каком-либо из вышеприведенных вариантов осуществления.

[00634] Либо инициатор запроса, в котором установлена микросхема 1600, выполнен с возможностью осуществления этапов, выполняемых инициатором запроса в каком-либо из вышеприведенных вариантов осуществления.

[00635] Либо сервер аутентификации, которому доверяет контроллер доступа при аутентификации, в котором установлена микросхема 1600, выполнен с возможностью осуществления этапов, выполняемых сервером аутентификации, которому доверяет контроллер доступа при аутентификации, в каком-либо из вышеприведенных вариантов осуществления.

[00636] Либо сервер аутентификации, которому доверяет инициатор запроса, в котором установлена микросхема 1600, выполнен с возможностью осуществления этапов, выполняемых сервером аутентификации, которому доверяет инициатор запроса, в каком-либо из вышеприведенных вариантов осуществления.

[00637] Запоминающее устройство 1602 может быть включено в микросхему 1600 или запоминающее устройство 1602 может быть обеспечено вне микросхемы 1600.

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

[00639] Либо компьютерная программа обеспечивает возможность для инициатора запроса, в котором установлена микросхема, осуществлять этапы, выполняемые инициатором запроса, в каком-либо из вышеприведенных вариантов осуществления.

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

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

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

[00643] Либо компьютерная программа обеспечивает возможность для инициатора запроса, в котором установлена микросхема, осуществлять этапы, выполняемые инициатором запроса, в каком-либо из вышеприведенных вариантов осуществления.

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

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

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

[00647] Каждый компонент, микросхема или процессор в вариантах осуществления настоящего раскрытия может представлять собой микросхему с интегральными схемами и может иметь возможность обработки сигнала. В ходе реализации каждый этап вариантов осуществления способа может выполняться интегральной логической схемой аппаратных средств в процессоре или инструкцией в программной форме. Каждый компонент, микросхема или процессор может включать в себя набор из какого-либо одного или по меньшей мере двух из следующих элементов: универсальный процессор, специализированная интегральная схема (Application Specific Integrated Circuit, ASIC), цифровой сигнальный процессор (Digital Signal Processor, DSP), устройство цифровой обработки сигналов (Digital Signal Processing Device, DSPD), программируемое логическое устройство (Programmable Logic Device, PLD), программируемая пользователем вентильная матрица (Field Programmable Gate Array, FPGA), центральный процессор (Central Processing Unit, CPU), графический процессор (Graphics Processing Unit, GPU), нейросетевой процессор (Neural-network Processing Unit, NPU), контроллер, микроконтроллер, микропроцессор, программируемое логическое устройство, устройство с логическим элементом на дискретных компонентах или с транзисторными логическими схемами; и дискретный аппаратный компонент.

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

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

ПРОМЫШЛЕННАЯ ПРИМЕНИМОСТЬ

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

Изобретение относится к средствам аутентификации идентификационной информации. Технический результат – повышение конфиденциальности информации, относящейся к идентификационной информации объекта. Конфиденциальную обработку выполняют в отношении идентификационной информации запрашивающего устройства и контроллера доступа при аутентификации таким образом, чтобы не раскрыть идентификационную информацию запрашивающего устройства и контроллера доступа при аутентификации в процессе передачи, таким образом гарантируя, что злоумышленник не сможет получить личную и конфиденциальную информацию запрашивающего устройства и контроллера доступа при аутентификации. Кроме того, путем применения сервера аутентификации реализуется взаимная аутентификация идентификационной информации запрашивающего устройства и контроллера доступа при аутентификации, при этом обеспечивается конфиденциальность информации, относящейся к идентификационной информации объекта. 4 н. и 11 з.п. ф-лы, 16 ил.

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

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

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

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

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

- прием контроллером доступа при аутентификации первого ответного сообщения об аутентификации, отправленного первым сервером аутентификации,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. Способ по любому из пп. 2-4, согласно которому:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- отправку первым сервером аутентификации второго сообщения с запросом аутентификации на второй сервер аутентификации,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

14. Инициатор запроса, содержащий процессор и запоминающее устройство,

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

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

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