СПОСОБ КОНФИГУРИРОВАНИЯ КЛЮЧА, СПОСОБ ОПРЕДЕЛЕНИЯ ПОЛИТИКИ БЕЗОПАСНОСТИ И УСТРОЙСТВО

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

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

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

[0002] В будущей архитектуре (например, 5-м поколении) мобильной связи сетевой элемент управления сеансами устанавливает сеанс между пользовательским оборудованием и шлюзом (или сервером DN, или другим пользовательским оборудованием) на основе потребности в услуге пользовательского оборудования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0018] В одной реализации UPF является UPF в гостевой наземной сети мобильной связи общего пользования (VPLMN), а требование к возможностям по обеспечению безопасности от сети оператора связи является требованием по обеспечению безопасности шлюза в VPLMN; или UPF является UPF в домашней наземной сети мобильной связи общего пользования (HPLMN), а требование к возможностям по обеспечению безопасности от сети оператора связи является требованием по обеспечению безопасности шлюза в HPLMN.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0032] В одной реализации запрос дополнительно включает в себя:

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

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

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

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

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

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

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

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

[0040] В одной реализации этап, на котором получают требование по обеспечению безопасности сети оператора связи, включает в себя этап, на котором: после этапа, на котором принимают запрос политики безопасности, локально получают предварительно сохраненное требование по обеспечению безопасности сети оператора связи.

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

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

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

[0044] В одной реализации UPF является UPF в гостевой наземной сети мобильной связи общего пользования (VPLMN), а требование к возможностям по обеспечению безопасности от сети оператора связи является требованием по обеспечению безопасности шлюза в VPLMN; или UPF является UPF в домашней наземной сети мобильной связи общего пользования (HPLMN), а требование к возможностям по обеспечению безопасности от сети оператора связи является требованием по обеспечению безопасности шлюза в HPLMN.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0058] Четырнадцатый аспект этой заявки обеспечивает сетевой элемент управления сеансами, включающий в себя:

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

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

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

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

[0062] Шестнадцатый аспект этой заявки обеспечивает пользовательское оборудование, включающее в себя:

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

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

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

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

[0066] Восемнадцатый аспект этой заявки обеспечивает сетевой элемент управления политикой или сетевой элемент управления мобильностью, включающий в себя: процессор, выполненный с возможностью: определения оконечной точки обеспечения безопасности; когда оконечная точка обеспечения безопасности является узлом плоскости пользователя (UPF), генерации политики безопасности на основе по меньшей мере одного из: требования пользователя по обеспечению безопасности, которое относится к пользовательскому оборудованию и которое предварительно сконфигурировано на сервере абонентов, требования услуги по обеспечению безопасности от пользовательского оборудования и требования к возможностям по обеспечению безопасности, поддерживаемым пользовательским оборудованием, и по меньшей мере одного из: требования к возможностям по обеспечению безопасности от сети оператора связи и требования по обеспечению безопасности устройства на другом конце сквозной связи; или когда оконечная точка обеспечения безопасности является другим устройством, генерации политики безопасности на основе требования по обеспечению безопасности другого устройства и по меньшей мере одного из: требования пользователя по обеспечению безопасности, которое относится к пользовательскому оборудованию и которое предварительно сконфигурировано на сервере абонентов, требования услуги по обеспечению безопасности от пользовательского оборудования и требования к возможностям по обеспечению безопасности, поддерживаемым пользовательским оборудованием, при этом другое устройство включает в себя точку ветвления или ULCL.

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

[0068] В одной реализации UPF является UPF в гостевой наземной сети мобильной связи общего пользования (VPLMN), а требование к возможностям по обеспечению безопасности от сети оператора связи является требованием по обеспечению безопасности шлюза в VPLMN; или UPF является UPF в домашней наземной сети мобильной связи общего пользования (HPLMN), а требование к возможностям по обеспечению безопасности от сети оператора связи является требованием по обеспечению безопасности шлюза в HPLMN.

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

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

[0070] Фиг. 1 является схематическим чертежом будущей сетевой архитектуры мобильной связи;

[0071] фиг. 2 является блок-схемой последовательности операций способа определения политики безопасности в соответствии с одним вариантом осуществления этой заявки;

[0072] фиг. 3 является блок-схемой последовательности операций другого способа определения политики безопасности в соответствии с одним вариантом осуществления этой заявки;

[0073] фиг. 4 является блок-схемой последовательности операций другого способа определения политики безопасности в соответствии с одним вариантом осуществления этой заявки;

[0074] фиг. 5 является блок-схемой последовательности операций другого способа определения политики безопасности в соответствии с одним вариантом осуществления этой заявки;

[0075] фиг. 6 является блок-схемой последовательности операций другого способа определения политики безопасности в соответствии с одним вариантом осуществления этой заявки;

[0076] фиг. 7 является блок-схемой последовательности операций другого способа определения политики безопасности в соответствии с одним вариантом осуществления этой заявки;

[0077] фиг. 8 является блок-схемой последовательности операций способа конфигурирования ключа в соответствии с одним вариантом осуществления этой заявки;

[0078] фиг. 9 является блок-схемой последовательности операций другого способа конфигурирования ключа в соответствии с одним вариантом осуществления этой заявки;

[0079] фиг. 10 является блок-схемой последовательности операций другого способа конфигурирования ключа в соответствии с одним вариантом осуществления этой заявки;

[0080] фиг. 11 является блок-схемой последовательности операций другого способа конфигурирования ключа в соответствии с одним вариантом осуществления этой заявки;

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

[0082] фиг. 13 является блок-схемой последовательности операций другого способа конфигурирования ключа в соответствии с одним вариантом осуществления этой заявки;

[0083] фиг. 14 является блок-схемой последовательности операций другого способа конфигурирования ключа в соответствии с одним вариантом осуществления этой заявки;

[0084] фиг. 15 является блок-схемой последовательности операций другого способа конфигурирования ключа в соответствии с одним вариантом осуществления этой заявки;

[0085] фиг. 16 (a) и фиг. 16 (b) являются схематическими чертежами сценария ветвления;

[0086] фиг. 17 является схематическим чертежом сценария, в котором линией связи сеанса является UE-AN-UPF (ULCL)-UPF (привязка);

[0087] фиг. 18 является схематическим чертежом сценария роуминга с домашней маршрутизацией;

[0088] фиг. 19 является схематическим структурным чертежом сетевого элемента управления сеансами в соответствии с одним вариантом осуществления этой заявки; и

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

ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

[0090] Далее описаны технические решения в вариантах осуществления настоящего изобретения со ссылкой на прилагаемые чертежи в вариантах осуществления настоящего изобретения.

[0091] Фиг. 1 показывает будущую сетевую архитектуру мобильной связи.

[0092] Пользовательское оборудование (англ.: User Equipment, UE) является логическим объектом и может, в частности, включать в себя:

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

[0093] UE осуществляет доступ к сети оператора связи путем использования сети доступа (англ.: Access Network, AN).

[0094] Сеть оператора связи включает в себя:

сетевой элемент управления мобильностью (англ.: Mobility Management, MM);

сетевой элемент управления сеансами (англ.: Session Management, SM), выполненный с возможностью установления сеанса и управления сеансом, временным интервалом, потоком или несущей;

блок аутентификации (англ.: Authentication Unit или Authentication Function, AU или AF), выполненный с возможностью выполнения двусторонней аутентификации с UE, где AU может быть развернут отдельно как независимый логический функциональный объект или может быть развернут внутри MM или SM, другими словами, MM или SM играет роль AU;

серверный узел или сервер абонентов оператора связи, включающий в себя сервер AAA (англ.: Authentication, Authorization, Accounting server (сервер аутентификации, авторизации, учета)), сервер абонентов (англ.: Home Subscriber Server, HSS), центр аутентификации (англ.: Authentication Center, AuC), или центр регистрационной информации абонентов (англ.: subscriber repository (хранилище абонентов)) оператора связи, где для простоты описания ниже единообразно используется AAA, и AAA хранит аутентификационную информацию и абонентскую информацию каждого UE, например, корневой ключ аутентификации, алгоритм безопасности и регистрационную информацию абонента;

сетевой элемент управления политикой (Policy control), который используется для согласования политики;

центр управления ключами (англ.: Key Management System, KMS), который отвечает за генерацию ключей, управление и согласование и поддерживает законный перехват, при этом KMS может быть развернут отдельно как независимый логический функциональный объект или может быть развернут внутри AU, MM или SM, другими словами, AU, MM или SM играет роль KMS;

шлюз, также называемый шлюзом плоскости пользователя (англ.: User Plane-Gateway, UP-GW), выполненный с возможностью соединения сети оператора связи и сети передачи данных (англ.: Data Network, DN), где AN также может быть соединена с DN c использованием GW; и

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

[0095] Следует отметить, что фиг. 1 показывает логическую связь между сетевыми элементами. На практике каждый из MM, AU и SM может быть развернут независимо или может быть развернут в одном объекте посредством попарной интеграции. Например, SM и MM развернуты в одном объекте, а AU развернут независимо; или SM и AU развернуты в одном объекте, а MM развернут независимо.

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

[0097] Устройство конфигурирования ключей включает в себя модуль определения политики безопасности и модуль конфигурирования ключей. Модуль определения политики безопасности выполнен с возможностью определения политики безопасности на основе по меньшей мере одного из: требования по обеспечению безопасности одного конца (а именно UE 1) сквозной связи, требования по обеспечению безопасности другого конца (а именно сервера DN или UE 2) сквозной связи и требования по обеспечению безопасности сети оператора связи (а именно шлюза). Модуль конфигурирования ключей выполнен с возможностью конфигурирования, на основе политики безопасности и совместно используемого ключа между одним концом (а именно UE 1) сквозной связи и сетевым элементом (например, AU, KMS, SM или MM) сети оператора связи, ключа защиты, используемого для защиты сквозной связи (а именно, между UE 1 и сервером DN или UE 2).

[0098] Совместно используемый ключ может быть предварительно сконфигурированным совместно используемым ключом между UE и сетевым элементом (например, AU, KMS, SM или MM) оператора связи. Альтернативно, совместно используемый ключ может быть получен после выполнения двусторонней аутентификации между UE и сетевым элементом (например, AU, KMS, SM или MM) в сети оператора связи, а затем совместно используемый ключ посылается другому сетевому элементу. Например, совместно используемый ключ получается во время двусторонней аутентификации между UE и AU, а затем AU посылает совместно используемый ключ KMS, SM или MM; или совместно используемый ключ может посылаться другому сетевому элементу после выполнения двусторонней аутентификации между UE и KMS (или SM, или MM).

[0099] Например, в LTE совместно используемый ключ, полученный после аутентификации, включает в себя, но не ограничивается только этим, по меньшей мере одно из: CK, IK и Kasme. совместно используемый ключ включает в себя, но не ограничивается только этим, форму ключа, полученную после аутентификации в LTE, или может включать в себя совместно используемый ключ, полученный после выполнения аутентификации другим образом, например, на основе сертификата, на основе идентичности или на основе пароля плоскости пользователя.

[0100] В частности, требование по обеспечению безопасности UE 1 на одном конце сквозной связи включает в себя требование пользователя по обеспечению безопасности (для упрощения последующего описания кратко называемого требованием 1 по обеспечению безопасности в вариантах осуществления этой заявки) UE 1, которое предварительно сконфигурировано в HSS, требование услуги по обеспечению безопасности (кратко называемого требованием 2 по обеспечению безопасности) от UE 1, и требование к возможностям по обеспечению безопасности (кратко называемого требованием 5 по обеспечению безопасности), поддерживаемым UE, например, UE поддерживает только алгоритм ZUC. Требование 1 по обеспечению безопасности является требованием пользователя по обеспечению безопасности, предварительно сконфигурированным в HSS, и оно существует в данных подписки пользователя. Требование 1 по обеспечению безопасности может храниться отдельно как параметр, или может быть частью QoS (англ.: Quality of Service (качество обслуживания)) пользователя в HSS. Требование 2 по обеспечению безопасности посылается пользовательским оборудованием (UE) сети оператора связи, когда UE 1 инициирует запрос связи.

[0101] Требование сети оператора связи по обеспечению безопасности, а именно шлюза, включает в себя требование к возможностям по обеспечению безопасности (кратко называемого требованием 3 по обеспечению безопасности) от сети оператора связи (стороны шлюза). Требование 3 по обеспечению безопасности хранится в сетевом элементе управления политикой, оно может храниться отдельно как параметр, или может быть частью QoS в сетевом элементе управления политикой, или может храниться в сетевом элементе SM.

[0102] Требование другого конца по обеспечению безопасности (кратко называемое требованием 4 по обеспечению безопасности), а именно сервера DN (или UE 2) сквозной связи имеет следующий вид: когда UE 1 устанавливает связь или сервер DN (или UE 2) инициирует установление связи, сервер DN или UE 2 должен участвовать в некоторых сценариях, или сервер DN или UE 2 делает запрос обеспечения безопасности, например, запрос на использование алгоритма безопасности ZUC.

[0103] Кроме того, также может быть включено требование сетевого элемента функции приложения (Application Function, AF). AF устанавливает связь с PCF с использованием интерфейса, или AF устанавливает связь со всеми сетевыми функциональными объектами (например, SMF (объектом управления сеансами, англ.: Session Management Function), AMF (объектом управления доступом и мобильностью, англ.: Access and Mobility Management Function) или PCF (сетевой элемент управления политикой, англ.: Policy Control Function)) в сети мобильной связи с использованием открытого сетевого функционального объекта в другой сети.

[0104] В частности, независимо от конкретного требования по обеспечению безопасности, содержание требования по обеспечению безопасности включает в себя алгоритм обеспечения безопасности и, опционально, может дополнительно включать в себя длину ключа и/или время обновления ключа (например, 6 часов, 12 часов, 1 день, 2 дня, 1 месяц или 1 год).

[0105] В частности, алгоритм обеспечения безопасности включает в себя алгоритм шифрования и/или алгоритм защиты целостности. Например, алгоритм шифрования используется для указания конкретного алгоритма шифрования, который должен использоваться для выполнения криптографической защиты, в том числе, но не ограничиваясь только этим, «пустое значение» («пустой» алгоритм, указывающий, что шифрование не применяется), AES, Snow 3G или ZUC. Алгоритм защиты целостности используется для указания конкретного алгоритма защиты целостности, который должен использоваться для выполнения защиты целостности, в том числе, но не ограничиваясь только этим, «пустое значение» («пустой» алгоритм, указывающий, что защита целостности не применяется), AES, Snow 3G, ZUC, HMAC и CMAC. Алгоритм обеспечения безопасности в одном требовании по обеспечению безопасности может включать в себя множество алгоритмов шифрования и/или множество алгоритмов защиты целостности. В этом случае требование по обеспечению безопасности дополнительно включает в себя ранжирование алгоритмов по приоритету; другими словами, указывается конкретный алгоритм, который имеет приоритет.

[0106] Например, длина ключа защиты равна 64 битам, 128 битам, 256 битам, 512 битам и т.п. Первая возможная ситуация заключается в следующем: требование по обеспечению безопасности включает в себя только одну длину ключа защиты, и длины ключей защиты являются одинаковыми в последующем шифровании и защите целостности и все равны длине ключа защиты, заданной в требовании по обеспечению безопасности. Вторая возможная ситуация заключается в следующем: требование по обеспечению безопасности включает в себя две длины ключа защиты. Одна используется для указания длины ключа шифрования, а другая используются для указания длины ключа защиты целостности.

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

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

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

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

[0111] Возможно множество вариантов формата требования по обеспечению безопасности. Некоторые варианты конкретных форматов представлены ниже в Таблицах 1-5.

Таблица 1

[0112] В Таблице 1 EA указывает алгоритм шифрования, IA указывает алгоритм защиты целостности, IEI требования по обеспечению безопасности указывает идентификатор требования по обеспечению безопасности, и длина содержания требования по обеспечению безопасности указывает длину содержания требования по обеспечению безопасности.

[0113] Из Таблицы 1 можно видеть, что требование по обеспечению безопасности включает в себя пять октетов. Октет 1 используется для указания идентичности требования по обеспечению безопасности, а октет 2 используется для указания длины содержания требования по обеспечению безопасности.

[0114] Октет 3 используется для указания, требуется ли алгоритм шифрования и длину ключа шифрования. Значение старшего значащего бита в октете 3 используется для указания, требуется ли алгоритм шифрования. 0 указывает, что алгоритм шифрования не требуется, а 1 указывает, что алгоритм шифрования требуется. Оставшиеся семь битов могут по-отдельности указывать длину ключа шифрования. Например, в Таблице 1 второй старший значащий бит указывает, что длина ключа шифрования равна 128, а последующие биты могут по-отдельности указывать, что длина ключа шифрования равна 256 и т.п. (Таблица 1 показывает только два примера: 128 и 256, а другие длины могут быть заданы на основе фактических требований). Когда значение бита, указывающего длину ключа шифрования, равно 0, это означает, что длина, обозначенная битом, не используется; когда значение бита, указывающего длину ключа шифрования, равно 1, это означает, что длина, обозначенная битом, используется. Если значения множества битов, указывающих длину ключа шифрования, равны 1, это означает, что требование по обеспечению безопасности поддерживает ключи шифрования различной длины.

[0115] Октет 4 используется для указания, требуется ли алгоритм защиты целостности и длину ключа защиты целостности. Значение старшего значащего бита в октете используется для указания, требуется ли алгоритм защиты целостности. 0 указывает, что алгоритм защиты целостности не требуется, а 1 указывает, что алгоритм защиты целостности требуется. Оставшиеся семь битов могут по-отдельности указывать длину ключа защиты целостности. Например, в Таблице 1, второй старший значащий бит указывает, что длина ключа защиты целостности равна 128, а последующие биты могут по-отдельности указывать, что длина ключа защиты целостности равна 256 и т.п. (Таблица 1 показывает только два примера: 128 и 256, а другие длины могут быть заданы на основе фактических требований). Когда значение бита, указывающего длину ключа защиты целостности, равно 0, это означает, что длина, обозначенная битом, не используется; когда значение бита, указывающего длину ключа защиты целостности, равно 1, это означает, что длина, обозначенная битом, используется. Если значения множества битов, указывающих длину ключа защиты целостности, равны 1, это означает, что требование по обеспечению безопасности поддерживает ключи защиты целостности разной длины.

[0116] Октет 5 является опциональным и используется для указания, необходимо ли обновить ключ и цикл обновления. Значение старшего значащего бита в октете 5 используется для указания, необходимо ли обновить ключ. 0 указывает, что нет необходимости обновлять ключ, а 1 указывает, что ключ необходимо обновить. Оставшиеся семь битов могут по-отдельности указывать цикл обновления. Например, в Таблице 1 второй старший значащий бит указывает, что цикл обновления равен 24 часам, а последующие биты по-отдельности могут указывать, что цикл обновления равен 48 часам и т.п. (Таблица 1 показывает только два примера: 24 часа и 48 часов, а другие циклы могут быть заданы на основе фактических требований). Когда значение бита, указывающего цикл обновления, равно 0, это означает, что цикл не используется; когда значение бита, указывающего цикл обновления, равно 1, это означает, что цикл используется. Если значения множества битов, указывающих цикл обновления, равны 1, это означает, что требование по обеспечению безопасности поддерживает множество циклов обновления.

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

Таблица 2

[0118] Таблица 2 отличается от Таблицы 1 тем, что старшие значащие биты октетов с 3 по 5 все обозначены как «пустое значение». Если значение старшего значащего бита равно 1, это указывает «пустой» алгоритм; другими словами, никакой алгоритм не требуется. Например, если значение старшего значащего бита в октете 3 равно 1, это означает, что вычисление шифрования не требуется; а если значение старшего значащего бита в октете 3 равно 0, это означает, что требуется вычисление шифрования (альтернативно, смысл значений может быть обратным). Альтернативно, старшие значащие биты октета 3 и октета 4 представляют собой длину ключа равную 0, и если значение старшего значащего бита равно 1, это означает, что шифрование не требуется.

Таблица 3

[0119] В Таблице 3 EEA0 указывает алгоритм 0 шифрования развитой пакетной системы (Evolved Packet System, EPS), где EEA представляет собой алгоритм шифрования EPS (EPS encryption algorithm). EIA0 указывает алгоритм 0 защиты целостности EPS, где EIA представляет собой алгоритм целостности EPS (EPS integrity algorithm).

[0120] UEA0 указывает алгоритм 0 шифрования универсальной системы мобильной связи (Universal Mobile Telecommunications System, UMTS), где UEA представляет собой алгоритм шифрования UMTS, а именно, UMTS encryption algorithm. UIA0 указывает алгоритм 0 целостности UMTS, где UIA представляет собой алгоритм целостности UMTS, а именно, UMTS integrity algorithm.

[0121] Запасной бит указывает неактивный бит, он установлен равным 0.

[0122] GEA указывает алгоритм шифрования услуги пакетной радиосвязи общего пользования (General Packet Radio Service, GPRS), а именно, GPRS encryption algorithm.

[0123] Октеты 5 и 6 являются опциональными. Например, когда необходима поддержка технологии доступа UMTS, должны быть включены октет 5 и октет 6; когда необходима поддержка технологии доступа GPRS, должен быть включен октет 7.

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

Таблица 4

[0125] Таблица 4 отличается от Таблицы 3 тем, что добавлены октеты 8-10 по сравнению с Таблицей 3. Для определений октетов 8-10 см. Таблицу 1. Для определений октетов 3-7 см. Таблицу 4.

[0126] Кроме того, октеты 8-10 могут быть заменены функциями октетов 3-5 в Таблице 2. В этом случае, для описаний функций октетов 3-5 см. Таблицу 2.

Таблица 5

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

[0128] NEA0 указывает алгоритм 0 шифрования связи следующего поколения, где NEA представляет собой алгоритм шифрования следующего поколения, а именно, next-generation encryption algorithm. NIA0 указывает алгоритм 0 защиты целостности следующего поколения, где NIA представляет собой алгоритм целостности следующего поколения, а именно, next-generation integrity algorithm.

[0129] Кроме того, другие возможности включают в себя механизм обработки, аналогичный таковому в Таблице 4. Таблица 5 комбинируется с Таблицей 1 для отражения расширенного требования по обеспечению безопасности; или Таблица 5 комбинируется с Таблицей 2 для отражения расширенного требования по обеспечению безопасности.

[0130] Приведенные выше Таблицы 1-3 и Таблица 4 дополнительно включают в себя следующую возможность: включена только одна длина ключа, и в этом случае длина ключа шифрования является такой же, как длина ключа защиты целостности.

[0131] Следует отметить, что Таблицы с 1 по 5 являются просто примерами формата требования по обеспечению безопасности. Кроме того, требование по обеспечению безопасности может дополнительно включать в себя такое содержание, как приоритет (указываемый битовым значением в конкретном формате) требования по обеспечению безопасности, или требование по обеспечению безопасности включает в себя по меньшей мере одно из приведенного выше содержания.

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

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

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

[0135] Следует отметить, что защита сквозной связи в этой заявке включает в себя сквозную защиту сеанса, а также включает в себя сквозную защиту, которая основана на временном интервале, потоке или несущей. Сквозная защита сеанса используется в качестве примера ниже для описания. Поскольку UE 2 не включен в последующие чертежи, в дальнейшем UE является UE 1.

[0136] Модуль определения политики безопасности может быть расположен в UE 1, сетевой элемент (например, AN, MM, AU, KMS, AAA, SM или сетевой элемент управления политикой) в сети оператора связи, шлюзе, сетевой элемент (например, сервер DN) в DN или UE 2, показанных на фиг. 1. Политика безопасности может быть определена в процессе подключения к сети UE или может быть определена после того, как UE подключилось к сети. Ниже по-отдельности представлены описания с использованием примеров, в которых модуль определения политики безопасности расположен в сетевом элементе управления политикой и в которых модуль определения политики безопасности расположен в SM.

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

[0138] 1. В процессе подключения к сети UE 1 получает доступ к сети, и после выполнения двусторонней аутентификации AU получает требование 1 по обеспечению безопасности от AAA.

[0139] Следует отметить, что сервер абонентов принимает запрос требования по обеспечению безопасности AU, который включает в себя идентификатор пользователя, определяет требование 1 по обеспечению безопасности на основе идентификатора пользователя, а затем посылает требование 1 по обеспечению безопасности блоку аутентификации (AU).

[0140] 2. AU посылает требование 1 по обеспечению безопасности сетевому элементу управления мобильностью (MM).

[0141] 3. MM генерирует идентификатор (Identity, ID) сети, например, ID сеанса, и инициирует запрос сеанса к SM. Запрос сеанса включает в себя:

[0142] (a) ID UE: используемый сетью для идентификации пользователя, включающий, но не ограничивающийся только этим, по меньшей мере одно из: IMEI, международный идентификатор мобильного абонента (International Mobile Subscriber Identity, IMSI), приватный идентификатор IP-мультимедиа (IP Multimedia Private Identity, IMPI), TMSI, публичный идентификатор IP-мультимедиа (IP Multimedia Public Identity, IMPU), ID приложения пользователя, MAC-адрес, IP-адрес, номер мобильного телефона и GUTI. Для простоты описания в последующих вариантах осуществления единообразно используется ID UE.

[0143] (b) ID сети (опционально): используемый сетью для идентификации процедуры (например, временного интервала, несущей, сеанса или потока), в которой находится пользователь, включающий в себя, но не ограничивающийся только этим, по меньшей мере одно из: ID сеанса, ID несущей, ID потока, ID временного интервала и ID PLMN.

[0144] (c) требование 1 по обеспечению безопасности.

[0145] (d) Параметр услуги (опционально): используемый сетью для идентификации услуги или приложения пользователя и соответствующий признак услуги, включающий по меньшей мере одно из: ID услуги, ID приложения, ID сервера, порядковый номер SN в услуге, метку времени и параметр свежести (Fresh parameter 1).

[0146] Следует отметить, что приведенный выше ID UE и/или параметр услуги может быть получен MM из сообщения доступа, посланного UE сетевому элементу управления мобильностью (MM); или может быть получен непосредственно от AU или AAA, и в этом случае AU или AAA получает ID UE и/или параметр услуги из сообщения, используемого UE для получения доступа к сети.

[0147] Кроме того, MM может непосредственно получить требование 1 по обеспечению безопасности от AAA.

[0148] Кроме того, когда UE осуществляет доступ к сети, UE может послать сети требование 2 по обеспечению безопасности и/или требование 5 по обеспечению безопасности, и в этом случае запрос сеанса, посланный сетевым элементом управления мобильностью (MM), также включает в себя требование 2 по обеспечению безопасности и/или требование 5 по обеспечению безопасности.

[0149] 4. После приема запроса сеанса SM посылает требование 1 по обеспечению безопасности сетевому элементу управления политикой, и может дополнительно послать ID UE и ID сети (например, ID сеанса) сетевому элементу управления политикой.

[0150] Опционально, SM может добавить требование 1 по обеспечению безопасности к сообщению запроса политики и послать сообщение запроса политики сетевому элементу управления политикой. Опционально, сообщение запроса может дополнительно включать в себя по меньшей мере одно из: ID UE и ID сети.

[0151] Опционально, если SM принимает требование 2 по обеспечению безопасности и/или требование 5 по обеспечению безопасности от MM, SM посылает требование 2 по обеспечению безопасности и/или требование 5 по обеспечению безопасности управлению политикой.

[0152] 5. Сетевой элемент управления политикой получает предварительно сохраненное локально требование 3 по обеспечению безопасности или по меньшей мере одно из: требование 1 по обеспечению безопасности, требование 2 по обеспечению безопасности, требование 3 по обеспечению безопасности и требование 5 по обеспечению безопасности и определяет политику безопасности на основе требования 1 по обеспечению безопасности и требования 3 по обеспечению безопасности.

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

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

[0155] Например, если длина ключа защиты равна 64 в содержании требования 1 по обеспечению безопасности, и длина ключа защиты равна 128 в содержании требования 2 по обеспечению безопасности, в качестве длины ключа защиты в политике безопасности используется 128.

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

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

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

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

[0160] Альтернативно, если приоритеты алгоритмов указаны во множестве требований по обеспечению безопасности, в качестве основного приоритета может использоваться приоритет алгоритма конкретного требования по обеспечению безопасности. Например, приоритет требования 2 по обеспечению безопасности используется в качестве основного приоритета.

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

[0162] 6. Сетевой элемент управления политикой возвращает политику безопасности сетевому элементу управления сеансами (SM). Опционально, сетевой элемент управления политикой добавляет политику безопасности в ответное сообщение для возврата.

[0163] Следует отметить, что этапы 1-3 на фиг. 2 являются просто одной реализацией. Опционально, SM вместо MM может генерировать ID сети, такой как ID сеанса. А именно, SM генерирует ID сети, такой как ID сеанса, после приема запроса сеанса, посланного сетевым элементом управления мобильностью (MM).

[0164] Фиг. 3 показывает другую процедуру определения политики безопасности. Отличие от фиг. 2 состоит в следующем: после приема запроса сеанса в дополнение к ID сети и требованию 1 по обеспечению безопасности (и, вероятно, ID UE) SM посылает параметр услуги, например, по меньшей мере одно из: ID услуги и ID приложения, сетевому элементу управления политикой. После получения требования 1 по обеспечению безопасности сетевой элемент управления политикой посылает запрос требования по обеспечению безопасности серверу DN или UE 2 (не показано на фиг. 3). Запрос требования по обеспечению безопасности включает в себя по меньшей мере одно из: ID UE и параметр услуги (например, ID услуги или ID приложения). Сетевой элемент управления политикой принимает требование 4 по обеспечению безопасности, возвращенное сервером DN или UE 2. Сетевой элемент управления политикой определяет политику безопасности на основе требования 1 по обеспечению безопасности, требования 3 по обеспечению безопасности и требования 4 по обеспечению безопасности.

[0165] Конечно, SM может альтернативно послать запрос требования по обеспечению безопасности серверу DN или UE 2 и принять требование 4 по обеспечению безопасности, возвращенное сервером DN или UE 2, а затем SM посылает требование 4 по обеспечению безопасности сетевому элементу управления политикой. Предпочтительно, для упрощения процедуры взаимодействия, SM сначала может получать требование 4 по обеспечению безопасности, а затем посылать как требование 2 по обеспечению безопасности, так и требование 4 по обеспечению безопасности сетевому элементу управления политикой.

[0166] На фиг. 2 или фиг. 3 этап 1 и этап 2 являются процессами, в которых SM получает требование 1 по обеспечению безопасности и различные идентификаторы и параметры. Кроме того, сетевой элемент в сети оператора связи может дополнительно передавать требование 1 по обеспечению безопасности и различные идентификаторы и параметры сетевому элементу управления сеансами (SM) другими методами:

[0167] Первый метод:

[0168] 1. В процессе двусторонней аутентификации AU получает от AAA требование 1 по обеспечению безопасности, предварительно сохраненное в AAA.

[0169] 2. AU напрямую посылает запрос сеанса сетевому элементу управления сеансами (SM), не используя MM. Конкретное содержание запроса сеанса показано на фиг. 2 или фиг. 3. Подробности не будут описываться здесь повторно.

[0170] Второй способ:

[0171] 1. SM принимает запрос сеанса, отправленный AN, AU или MM. Запрос сеанса включает в себя по меньшей мере одно из: ID UE, идентификатор сети и параметр услуги.

[0172] 2. SM локально получает предварительно сохраненное требование 1 по обеспечению безопасности на основе ID UE.

[0173] Третий способ:

[0174] 1. SM принимает запрос сеанса, отправленный AN, AU или MM. Запрос сеанса включает в себя по меньшей мере одно из: ID UE, идентификатор сети и параметр услуги.

[0175] 2. SM получает предварительно сохраненное требование 1 по обеспечению безопасности от AAA, MM или AU.

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

[0177] Альтернативно, требование 1 по обеспечению безопасности может быть предварительно сохранено в другом сетевом элементе на фиг. 1 в дополнение к сетевому элементу управления политикой. Поскольку сетевой элемент управления политикой используется для согласования QoS в существующей сетевой архитектуре (например, LTE), хранение требование 3 по обеспечению безопасности в сетевом элементе управления политикой обеспечивает реализацию логической совместимости между решением для определения политики безопасности в этом варианте осуществления и существующей процедурой определения политики.

[0178] В приведенных выше методах, независимо от конкретного метода, для метода работы HSS следует смотреть процедуру, показанную на фиг. 2, при условии, что это относится к получению требования 1 по обеспечению безопасности. Подробности не будут описываться здесь повторно.

[0179] Фиг. 4 показывает другую процедуру определения политики безопасности. Отличие от фиг. 2 или фиг. 3 заключается в том, что UE 1 инициирует запрос сеанса после подключения UE к сети. В этом случае UE 1 может предоставить требование 2 по обеспечению безопасности и/или требование 5 по обеспечению безопасности, так что сетевой элемент управления политикой определяет политику безопасности на основе большего числа требований по обеспечению безопасности. Фиг. 4 включает в себя следующие этапы.

[0180] 1. После подключения к сети UE инициирует запрос сеанса к MM. Запрос сеанса включает в себя ID UE, требование по обеспечению безопасности и, опционально, может дополнительно включать в себя ID сети и/или параметр услуги.

[0181] В частности, требование по обеспечению безопасности включает в себя требование 2 по обеспечению безопасности и/или требование 5 по обеспечению безопасности. Конкретное содержание ID UE, требования по обеспечению безопасности, ID сети и параметра услуги является таким же, как было описано выше. Подробности не будут описываться здесь повторно.

[0182] Следует отметить, что в процессе двусторонней аутентификации, показанной на фиг. 2 или фиг. 3, запрос доступа, посланный UE, также может содержать требование 2 по обеспечению безопасности и/или требование 5 по обеспечению безопасности.

[0183] 2. Требование 1 по обеспечению безопасности сохраняется в MM. После приема запроса сеанса MM генерирует ID сети (например, ID сеанса), и MM посылает запрос сеанса сетевому элементу управления сеансами (SM). Запрос сеанса включает в себя требование 1 по обеспечению безопасности, требование 2 по обеспечению безопасности и/или требование 5 по обеспечению безопасности, ID UE, ID сети и может дополнительно включать в себя параметр услуги.

[0184] 3. После приема запроса сеанса SM посылает требование 1 по обеспечению безопасности и требование 2 по обеспечению безопасности и/или требование 5 по обеспечению безопасности сетевому элементу управления политикой и может дополнительно послать ID UE и ID сети (например, ID сеанса) сетевому элементу управления политикой.

[0185] 4. Сетевой элемент управления политикой определяет политику безопасности на основе требований по обеспечению безопасности, посланных SM и локально предварительно сохраненного требования 3 по обеспечению безопасности. Конкретное правило определения политики безопасности является таким же, как было описано выше. Подробности не будут описываться здесь повторно.

[0186] 5. Сетевой элемент управления политикой посылает политику безопасности сетевому элементу управления сеансами (SM).

[0187] Следует отметить, что этапы 1-3 на фиг. 4 являются просто одной реализацией. Опционально, запрос сеанса, посланный UE 1, может не содержать ID сети, и после приема запроса сеанса пользовательского оборудования 1 (UE 1) MM генерирует ID сети и посылает ID сети сетевому элементу управления сеансами (SM). Альтернативно, SM вместо MM может генерировать ID сети. Другими словами, после приема запроса сеанса, посланного сетевым элементом управления мобильностью (MM), SM генерирует ID сети, например, ID сеанса.

[0188] UE напрямую посылает запрос сеанса сетевому элементу управления сеансами (SM). В этом случае для метода получения требования 1 по обеспечению безопасности сетевым элементом управления сеансами (SM) см. приведенную выше процедуру получения.

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

[0190] Фиг. 5 показывает другую процедуру определения политики безопасности. Отличие от фиг. 4 заключается в том, что добавлен процесс получения требования 4 по обеспечению безопасности. В частности, после приема запроса сеанса в дополнение к ID UE, ID сети и требованиям по обеспечению безопасности SM посылает параметр услуги, например, по меньшей мере одно из: ID услуги и ID приложения сетевому элементу управления политикой. После получения требований по обеспечению безопасности, посланных SM, сетевой элемент управления политикой посылает запрос требования по обеспечению безопасности серверу DN или UE 2. Запрос требования по обеспечению безопасности включает в себя по меньшей мере одно из: ID UE и ID приложения. Сетевой элемент управления политикой принимает требование 4 по обеспечению безопасности, возвращенное сервером DN или UE 2. Сетевой элемент управления политикой определяет политику безопасности на основе требований по обеспечению безопасности, посланных SM, и требования 4 по обеспечению безопасности.

[0191] Конечно, альтернативно SM может послать запрос требования по обеспечению безопасности серверу DN или UE 2 и принять требование 4 по обеспечению безопасности, возвращенное сервером DN или UE 2, а затем SM посылает требование 4 по обеспечению безопасности сетевому элементу управления политикой. Для конкретных методов, с помощью которых SM получает требование 4 по обеспечению безопасности и посылает требование 4 по обеспечению безопасности сетевому элементу управления политикой, см. фиг. 4. Подробности не будут описываться здесь повторно.

[0192] В дополнение к реализации, показанной на фиг. 4 или фиг. 5, другие реализации получения требования 1 по обеспечению безопасности сетевым элементом управления сеансами (SM) могут дополнительно включить в себя следующее:

[0193] Первый метод:

[0194] 1. SM принимает запрос сеанса, посланный AN, AU или MM. Запрос сеанса показан на фиг. 4 или фиг. 5.

[0195] 2. SM локально получает предварительно сохраненное требование 1 по обеспечению безопасности на основе ID UE.

[0196] Второй метод:

[0197] 1. SM принимает запрос сеанса, посланный AN, AU или MM. Запрос сеанса показан на фиг. 4 или фиг. 5.

[0198] 2. SM получает предварительно сохраненное требование 1 по обеспечению безопасности от AAA, MM или AU.

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

[0200] Когда SM определяет политику безопасности на основе требований по обеспечению безопасности, для процессов, в которых SM получает требование 1 по обеспечению безопасности, требование 2 и/или 5 по обеспечению безопасности, ID UE, ID сети и параметр услуги, см. фиг. 2 - фиг. 5. Подробности не будут описываться здесь повторно. SM может получить требование 4 по обеспечению безопасности с помощью методов, показанных на фиг. 2 - фиг. 5. Альтернативно, сетевой элемент управления политикой получает требование 4 по обеспечению безопасности с помощью методов, показанных на фиг. 2 - фиг. 5, а затем SM принимает требование 4 по обеспечению безопасности, посланное сетевым элементом управления политикой. SM может послать запрос требования по обеспечению безопасности (включающий в себя по меньшей мере одно из: ID UE, ID сети или параметр услуги) сетевому элементу управления политикой для получения требования 3 по обеспечению безопасности от сетевого элемента управления политикой. Фиг. 6 и фиг. 7 являются просто примерами, в которых SM определяет политику безопасности. Не все случаи изображены в настоящем описании.

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

[0202] В приведенных выше процедурах ID сеанса, ID несущей, ID потока или ID временного интервала в ID сети генерируется сетевым элементом в сети оператора связи, например, AN, MM, AU, KMS, AAA, SM или сетевым элементом управления политикой. Кроме того, ID сеанса, ID несущей, ID потока или ID временного интервала альтернативно могут генерироваться UE 1, передаваться в запросе подключения или запросе сеанса, посылаемом UE 1 сети оператора связи, и посылаться сетевому элементу в сети оператора связи, например, AN, MM, AU, KMS, AAA, SM или сетевому элементу управления политикой. Например, на фиг. 2 перед двусторонней аутентификацией UE 1 посылает сети оператора связи сообщение запроса подключения, которое содержит ID сеанса, ID несущей, ID потока или ID временного интервала (оно принадлежит процессу, в котором UE 1 подключается к сети оператора связи). В качестве другого примера на фиг. 4 запрос сеанса, посланный UE 1 сетевому элементу управления мобильностью (MM), дополнительно содержит ID сеанса, ID несущей, ID потока или ID временного интервала.

[0203] Когда UE 1 генерирует и посылает ID сеанса, ID несущей, ID потока или ID временного интервала сети оператора связи, сетевой элемент в сети оператора связи, например, AN, MM, AU, KMS, AAA, SM или сетевой элемент управления политикой, больше не генерирует ID сеанса, ID несущей, ID потока или ID временного интервала.

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

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

[0206] Модуль конфигурирования ключей может быть расположен в одном или более из: UE 1, сетевом элементе (например, AN, MM, AU, KMS, AAA, SM или сетевом элементе управления политикой), в сети оператора связи, шлюзе, сетевом элементе (например, сервере DN) в DN или UE 2. Сторона генерации ключа защиты должна получить политику безопасности и совместно используемый ключ K, чтобы вычислить ключ защиты и раздать ключ защиты другим сетевым элементам, таким как UE и шлюз (или сервер DN, или UE 2). В частности, сторона генерации ключа защиты может посылать ключ защиты центру управления ключами (KMS), и KMS посылает ключ защиты другим сетевым элементам, таким как UE и шлюз (или сервер DN, или UE 2); или может напрямую раздавать ключ защиты другим сетевым элементам, таким как UE и шлюз (или сервер DN, или UE 2).

[0207] Далее для описания используется пример, в котором модуль конфигурирования ключей расположен в одном или более из: SM, KMS или UE.

[0208] Фиг. 8, в частности, включает в себя следующие этапы.

[0209] 1. SM посылает сообщение запроса ключа центру управления ключами (KMS). Сообщение запроса ключа включает в себя ID UE и политику безопасности и, опционально, дополнительно может включать в себя ID сети и/или параметр услуги. Конкретное содержание ID UE, политики безопасности, ID сети и параметра услуги является таким же, как было описано выше. Подробности не будут описываться здесь повторно.

[0210] Для метода получения политики безопасности см. фиг. 2 - фиг. 7. Если политика безопасности определяется сетевым элементом управления политикой, сетевой элемент управления политикой посылает политику безопасности сетевому элементу управления сеансами (SM).

[0211] 2. KMS вычисляет ключ защиты на основе политики безопасности и совместно используемого ключа K. Ключ защиты используется для защиты сеанса между UE и шлюзом (или сервером DN, или UE 2).

[0212] Совместно используемый ключ K между KMS и UE может быть выделен пользовательскому оборудованию (UE) и KMS в процессе, в котором UE получает доступ к сети и устанавливает контекст к MM, или может быть выделен пользовательскому оборудованию (UE) и KMS в процессе двусторонней аутентификации или после процесса двусторонней аутентификации, или может быть предварительно сконфигурирован на UE и KMS.

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

[0214] Ключ защиты имеет следующий вид:

K_SID=KDF (K, (по меньшей мере одно из: ID UE, ID сеанса, ID несущей, ID потока, ID временного интервала, ID PLMN, параметр услуги и одноразовый код), набор политик); или

K_SID=KDF (K, (по меньшей мере одно из: ID UE, ID сеанса, ID несущей, ID потока, ID временного интервала, ID PLMN, параметр услуги и одноразовый код)); или

K_{SID_enc}=KDF (K_SID, ID алгоритма шифрования, (по меньшей мере одно из: ID UE, ID сеанса, ID несущей, ID потока, ID временного интервала, ID PLMN, параметр услуги и одноразовый код)); или

K_{SID_enc}=KDF (K_SID, идентификатор шифрования, (по меньшей мере одно из: ID UE, ID сеанса, ID несущей, ID потока, ID временного интервала, ID PLMN, параметр услуги и одноразовый код)); или

K_{SID_enc}=KDF (K_SID, ID алгоритма шифрования).

[0215] Набор политик является политикой безопасности, а K является совместно используемым ключом между UE и KMS.

[0216] Как было описано выше, идентификатор шифрования может быть символьной строкой и использоваться для идентификации, что результатом выведения является ключ шифрования. Одноразовый код является случайным параметром и может выбираться KMS или добавляться в запрос сеанса пользовательским оборудованием (UE). Целью использования случайного числа для вычисления является улучшение безопасности и случайности ключа.

[0217] Ключ защиты целостности K_{SID_int} имеет следующий вид:

K_{SID_int}=KDF (K_SID, ID алгоритма защиты целостности); или

K_{SID_enc}=KDF (K_SID, идентификатор защиты целостности, (по меньшей мере одно из: ID UE, ID сеанса, ID несущей, ID потока, ID временного интервала, ID PLMN, параметр услуги и одноразовый код)); или

K_{SID_int}=KDF (K_SID, ID алгоритма защиты целостности, (по меньшей мере одно из: ID UE, ID сеанса, ID несущей, ID потока, ID временного интервала, ID PLMN, параметр услуги и одноразовый код)).

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

[0219] Приведенное выше KDF является функцией выведения ключа и включает в себя, но не ограничивается только этим, следующие функции выведения ключа: HMAC (такие как HMAC-SHA256 и HMAC-SHA1), NMAC, CMAC, OMAC, CBC-MAC, PMAC, UMAC, VMAC, хеш-алгоритм и т.п. Кроме того, требования в политике безопасности являются разными, например, длина ключа защиты должна равняться 256 битам в политике 1 безопасности, и длина ключа защиты должна равняться 128 битам в политике 2 безопасности. Поэтому KMS может использовать различные алгоритмы выведения ключа для выполнения требований по различным длинам ключа защиты в различных политиках безопасности (например, HMAC-SHA1 используется для генерации 128-битного ключа защиты, а HMAC-SHA256 используется для генерации 256-битного ключа защиты). Кроме того, KMS может генерировать ключ защиты с использованием только одного алгоритма, а затем генерировать ключ защиты другой длины посредством усечения (truncate), удлинения и т.п. Методы, с помощью которых KMS обрабатывает длину ключа защиты, включают в себя, но не ограничиваются только этим, приведенные выше методы обработки.

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

[0221] 3. KMS посылает ключ защиты, который может дополнительно включать в себя ID UE и/или ID сети, сетевому элементу управления сеансами (SM).

[0222] 4. SM раздает ключ защиты, ID сети и ID UE шлюзу (или серверу DN, или UE 2) и UE 1. В частности, SM может добавить ключ защиты в сообщение установления плоскости пользователя (User Plane Setup) и отправить сообщение установления плоскости пользователя шлюзу (или серверу, или UE 2) и добавить ключ защиты в сообщение о завершении установления сеанса (Session Setup Complete) и отправить сообщение о завершении установления сеанса пользовательскому оборудованию (UE).

[0223] Альтернативно, KMS может напрямую послать ID сети и ключ защиты шлюзу (или серверу DN, или UE 2). Посланное сообщение может дополнительно включать в себя ID UE.

[0224] Если при выведении ключа защиты используется одноразовый код, KMS также посылает одноразовый код сетевому элементу управления сеансами (SM), а затем SM посылает одноразовый код пользовательскому оборудованию (UE), или KMS напрямую посылает одноразовый код пользовательскому оборудованию (UE).

[0225] Фиг. 9 отличается от фиг. 8 тем, что UE принимает политику безопасности от SM и вычисляет ключ защиты на основе политики безопасности. Если при вычислении ключа защиты UE должен использовать случайный параметр, то KMS может посылать случайный параметр UE, или он может генерироваться UE.

[0226] Альтернативно, KMS может посылать ключ защиты сетевому элементу управления мобильностью (MM). В частности, MM может запросить ключ защиты сеанса у KMS после отправки запроса сеанса сетевому элементу управления сеансами (SM) и приема ответа сеанса, посланного сетевым элементом управления сеансами (SM).

[0227] Альтернативно, совместно используемый ключ K может быть предварительно сохранен в SM; или KMS получает совместно используемый ключ K после выполнения двусторонней аутентификации между UE и AU, а затем KMS посылает совместно используемый ключ K сетевому элементу управления сеансами (SM). Как UE, так и SM вычисляют ключ защиты.

[0228] Фиг. 10 показывает другой способ получения ключа в соответствии с одним вариантом осуществления этой заявки. Способ включает в себя следующие этапы.

[0229] 1. SM посылает сообщение запроса ключа центру управлению ключами (KMS). Сообщение запроса ключа включает в себя ID UE и политику безопасности и, опционально, может дополнительно включать в себя ID сети и/или параметр услуги. Конкретное содержание ID UE, требования по обеспечению безопасности, ID сети и параметра услуги является таким же, как было описано выше. Подробности не будут описываться здесь повторно.

[0230] Для метода получения политики безопасности см. фиг. 2 - фиг. 7. Если политика безопасности определяется сетевым элементом управления политикой, сетевой элемент управления политикой посылает политику безопасности сетевому элементу управления сеансами (SM).

[0231] 2. KMS вычисляет первый ключ на основе политики безопасности и совместно используемого ключа K. Первый ключ используется для защиты сеанса между UE и шлюзом (или сервером (включающем в себя сервер в DN или сети оператора связи, кратко называемый ниже сервером), или контроллером (включающем в себя контроллер в DN или сети оператора связи, кратко называемый ниже контроллером), или UE 2).

[0232] Совместно используемый ключ K между KMS и UE может быть выделен пользовательскому оборудованию (UE) и KMS в процессе, в котором UE получает доступ к сети и устанавливает контекст к MM, или может быть выделен пользовательскому оборудованию (UE) и KMS в процессе двусторонней аутентификации или после процесса двусторонней аутентификации, или может быть предварительно сконфигурирован на UE и KMS.

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

[0234] первый ключ (а именно, первый ключ является ключом защиты в приведенном выше варианте осуществления и единообразно называется ниже ключом защиты для единообразия с приведенным выше вариантом осуществления) имеет следующий вид:

K_SID=KDF (K, (по меньшей мере одно из: ID UE, ID сеанса, ID несущей, ID потока, ID временного интервала, ID PLMN, параметр услуги и одноразовый код), набор политик); или

K_SID=KDF (K, (по меньшей мере одно из: ID UE, ID сеанса, ID несущей, ID потока, ID временного интервала, ID PLMN, параметр услуги и одноразовый код)).

[0235] Ключ K_{SID_enc} криптографической защиты имеет следующий вид:

K_{SID_enc}=KDF (K, (по меньшей мере одно из: ID алгоритма шифрования, ID UE, ID сеанса, ID несущей, ID потока, ID временного интервала, ID PLMN, параметр услуги, одноразовый код и набор политик)); или

K_{SID_enc}=KDF (K, (по меньшей мере одно из: идентификатор шифрования, ID UE, ID сеанса, ID несущей, ID потока, ID временного интервала, ID PLMN, параметр услуги, одноразовый код и набор политик)).

[0236] Набор политик является политикой безопасности, а K является совместно используемым ключом между UE и KMS. Определение ID UE является таким же, как было описано в приведенных выше вариантах осуществления.

[0237] Как было описано выше, идентификатор шифрования может быть символьной строкой и использоваться для идентификации, что результатом выведения является ключ шифрования. Одноразовый код является случайным параметром и может выбираться KMS или добавляться в запрос сеанса пользовательским оборудованием (UE). Целью использования случайного числа для вычисления является улучшение безопасности и случайности ключа. Альтернативно, по меньшей мере один из двух одноразовых кодов может использоваться при выведении ключа. Один одноразовый код от KMS (выбранный центром управления ключами (KMS) и напрямую посланный пользовательскому оборудованию (UE), или посланный SM пользовательскому оборудованию (UE)), а другой одноразовый код от UE (добавленный к запросу сеанса пользовательским оборудованием (UE)).

[0238] Ключ защиты целостности KSID_int имеет следующий вид:

K_{SID_int}=KDF (K, (по меньшей мере одно из: идентификатор защиты целостности, ID UE, ID сеанса, ID несущей, ID потока, ID временного интервала, ID PLMN, параметр услуги, одноразовый код и набор политик)); или

K_{SID_int}=KDF (K, (по меньшей мере одно из: ID алгоритма защиты целостности, ID UE, ID сеанса, ID несущей, ID потока, ID временного интервала, ID PLMN, параметр услуги, одноразовый код и набор политик)).

[0239] Идентификатор защиты целостности может быть символьной строкой и использоваться для идентификации, что результатом выведения является ключ защиты целостности. Одноразовый код является случайным параметром и может выбираться KMS или добавляться в запрос сеанса пользовательским оборудованием (UE). Целью использования случайного числа для вычисления является улучшение безопасности и случайности ключа. Альтернативно, по меньшей мере один из двух одноразовых кодов может использоваться при выведении ключа. Один одноразовый код от KMS (выбранный центром управления ключами (KMS) и напрямую посланный пользовательскому оборудованию (UE), или посланный SM пользовательскому оборудованию (UE)), а другой одноразовый код от UE (добавленный к запросу сеанса пользовательским оборудованием (UE)).

[0240] Приведенные выше используемые параметры, такие как ID несущей, ID потока, ID временного интервала и ID сеанса, могут передаваться в запросе сеанса, посланном пользовательским оборудованием (UE) вместе с приведенным выше требованием 2 по обеспечению безопасности и/или требованием 5 по обеспечению безопасности, или передаваться в запросе пользовательского оборудования (UE) на доступ к сети оператора связи в первый раз, или передаваться в сообщении запроса ключа. Кроме того, ID алгоритма шифрования и ID алгоритма защиты целостности могут быть содержанием политики безопасности.

[0241] 3. KMS посылает сетевому элементу управления сеансами (SM) ключ (а именно, по меньшей мере одно из: ключ K_SID защиты, ключ K_{SID_enc} криптографической защиты и ключ K_{SID_int} защиты целостности), полученный на этапе 2 и, возможно, ID UE и/или ID сети.

[0242] 4. SM раздает шлюзу (или серверу, или контроллеру, или UE 2) и UE 1 ключ (а именно по меньшей мере одно из: ключ K_SID защиты, ключ K_{SID_enc} криптографической защиты и ключ K_{SID_int} защиты целостности), полученный на этапе 2. Сообщение может дополнительно включать в себя по меньшей мере одно из: ID сети, ID UE и политику безопасности. В частности, SM может добавить ключ защиты в сообщение установления плоскости пользователя (User Plane Setup) и отправить сообщение установления плоскости пользователя шлюзу (или серверу, или контроллеру, или UE 2).

[0243] Альтернативно, на этапе 4 SM не посылает пользовательскому оборудованию (UE) ключ, полученный на этапе 2, а продолжает выполнять следующие этапы.

[0244] 5. SM посылает политику безопасности пользовательскому оборудованию (UE). Сообщение может дополнительно включать в себя по меньшей мере одно из: ID сети и ID UE.

[0245] 6. UE принимает политику безопасности от SM (или управления политикой или KMS) и вычисляет по меньшей мере одно из: K_SID, ключ K_{SID_enc} криптографической защиты и ключ K_{SID_int} защиты целостности на основе политики безопасности таким же образом, как было описано выше. Если UE должен использовать случайный параметр при вычислении ключа защиты, случайный параметр может посылаться KMS пользовательскому оборудованию (UE) или может генерироваться UE. Альтернативно, по меньшей мере один из двух одноразовых кодов может использоваться при выведении ключа. Один одноразовый код от KMS (выбранный KMS и напрямую отправленный пользовательскому оборудованию (UE) или отправленный SM пользовательскому оборудованию (UE)), а другой одноразовый код от UE (добавленный в запрос сеанса пользовательским оборудованием (UE)).

[0246] По меньшей мере одно из: ключ K_SID защиты, ключ K_{SID_enc} криптографической защиты и ключ защиты целостности, которые UE генерирует или получает от SM, были описано выше. Кроме того, UE может принимать от KMS (или сетевого элемента управления политикой) политику безопасности и по меньшей мере одно из: ключ K_SID защиты, ключ K_{SID_enc} криптографической защиты и ключ защиты целостности.

[0247] Фиг. 11 показывает другой способ конфигурирования ключа в соответствии с одним вариантом осуществления этой заявки. Способ включает в себя следующие этапы.

[0248] 1. SM посылает сообщение запроса ключа центру управлению ключами (KMS). Сообщение запроса ключа включает в себя ID UE и политику безопасности и, опционально, может дополнительно включать в себя ID сети и/или параметр услуги. Конкретное содержание ID UE, требования по обеспечению безопасности, ID сети и параметра услуги является таким же, как было описано выше. Подробности не будут описываться здесь повторно.

[0249] Для метода получения политики безопасности см. фиг. 2 - фиг. 7. Если политика безопасности определяется сетевым элементом управления политикой, сетевой элемент управления политикой посылает политику безопасности сетевому элементу управления сеансами (SM).

[0250] 2. KMS вычисляет ключ защиты на основе политики безопасности и совместно используемого ключа K. Ключ защиты используется для защиты сеанса между UE и шлюзом (или сервером, или контроллером, или UE 2).

[0251] Совместно используемый ключ K между KMS и UE может быть выделен пользовательскому оборудованию (UE) и KMS в процессе, в котором UE получает доступ к сети и устанавливает контекст к MM, или может быть выделен пользовательскому оборудованию (UE) и KMS в процессе двусторонней аутентификации или после процесса двусторонней аутентификации, или может быть предварительно сконфигурирован на UE и KMS.

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

[0253] Ключ защиты имеет следующий вид:

K_SID=KDF (K, (по меньшей мере одно из: ID UE, ID сеанса, ID несущей, ID потока, ID временного интервала, ID PLMN, параметр услуги и одноразовый код), набор политик); или

K_SID=KDF (K, (по меньшей мере одно из: ID UE, ID сеанса, ID несущей, ID потока, ID временного интервала, ID PLMN, параметр услуги и одноразовый код)).

[0254] Приведенные выше используемые параметры, такие как ID несущей, ID потока, ID временного интервала, ID алгоритма шифрования и ID сеанса, могут передаваться в запросе сеанса, посылаемом пользовательским оборудованием (UE) вместе с приведенным выше требованием 2 по обеспечению безопасности и/или требованием 5 по обеспечению безопасности, или передаваться в запросе пользовательского оборудования (UE) на получение доступа к сети оператора связи в первый раз, или передаваться в сообщении запроса ключа. Кроме того, ID алгоритма шифрования и ID алгоритма защиты целостности могут быть содержанием политики безопасности. Одноразовый код является случайным параметром и может быть выбран KMS или добавлен к запросу сеанса пользовательским оборудованием (UE). Целью использования случайного числа для вычисления является улучшение безопасности и случайности ключа. Альтернативно, по меньшей мере один из двух одноразовых кодов может использоваться при выведении ключа. Один одноразовый код от KMS (выбранный KMS и напрямую отправленный пользовательскому оборудованию (UE) или отправленный SM пользовательскому оборудованию (UE)), а другой одноразовый код от UE (добавленный в запрос сеанса пользовательским оборудованием (UE)).

[0255] 3. KMS посылает ключ K_SID защиты, который может дополнительно включать в себя ID UE и/или ID сети, сетевому элементу управления сеансами (SM).

[0256] 4. SM вычисляет ключ криптографической защиты и/или ключ защиты целостности на основе политики безопасности и K_SID. Методы вычисления включают в себя, но не ограничиваются только этим, следующие методы:

[0257] Ключ K_{SID_enc} криптографической защиты имеет следующий вид:

K_{SID_enc}=KDF (K_SID, (по меньшей мере одно из: ID алгоритма шифрования, ID UE, ID сеанса, ID несущей, ID потока, ID временного интервала, ID PLMN, параметр услуги, одноразовый код и набор политик)); или

K_{SID_enc}=KDF (K_SID, (по меньшей мере одно из: идентификатор шифрования, ID UE, ID сеанса, ID несущей, ID потока, ID временного интервала, ID PLMN, параметр услуги, одноразовый код и набор политик)).

[0258] Набор политик является политикой безопасности, а K является совместно используемым ключом между UE и KMS. ID UE является таким же, как было описано выше. Идентификатор шифрования может быть символьной строкой и использоваться для идентификации, что результатом выведения является ключ шифрования. Одноразовый код является случайным параметром и может выбираться KMS или добавляться в запрос сеанса пользовательским оборудованием (UE). Целью использования случайного числа для вычисления является улучшение безопасности и случайности ключа. Альтернативно, по меньшей мере один из двух одноразовых кодов может использоваться при выведении ключа. Один одноразовый код от KMS (выбранный центром управления ключами (KMS) и напрямую посланный пользовательскому оборудованию (UE), или посланный SM пользовательскому оборудованию (UE)), а другой одноразовый код от UE (добавленный к запросу сеанса пользовательским оборудованием (UE)).

[0259] Ключ защиты целостности K_{SID_int} имеет следующий вид:

K_{SID_int}=KDF (K_SID, (по меньшей мере одно из: идентификатор защиты целостности, ID UE, ID сеанса, ID несущей, ID потока, ID временного интервала, ID PLMN, параметр услуги, одноразовый код и набор политик)); или

K_{SID_int}=KDF (K_SID, (по меньшей мере одно из: ID алгоритма защиты целостности, ID UE, ID сеанса, ID несущей, ID потока, ID временного интервала, ID PLMN, параметр услуги, одноразовый код и набор политик)).

[0260] Идентификатор защиты целостности может быть символьной строкой и использоваться для идентификации, что результатом выведения является ключ защиты целостности. Одноразовый код является случайным параметром и может выбираться KMS или добавляться в запрос сеанса пользовательским оборудованием (UE). Целью использования случайного числа для вычисления является улучшение безопасности и случайности ключа. Альтернативно, по меньшей мере один из двух одноразовых кодов может использоваться при выведении ключа. Один одноразовый код от KMS (выбранный центром управления ключами (KMS) и напрямую посланный пользовательскому оборудованию (UE), или посланный SM пользовательскому оборудованию (UE)), а другой одноразовый код от UE (добавленный к запросу сеанса пользовательским оборудованием (UE)).

[0261] Приведенные выше используемые параметры, такие как ID несущей, ID потока, ID временного интервала и ID сеанса, могут передаваться в запросе сеанса, посланном пользовательским оборудованием (UE) вместе с приведенным выше требованием 2 по обеспечению безопасности и/или требованием 5 по обеспечению безопасности, или передаваться в запросе пользовательского оборудования (UE) на доступ к сети оператора связи в первый раз, или передаваться в сообщении запроса ключа. Кроме того, ID алгоритма шифрования и ID алгоритма защиты целостности могут быть содержанием политики безопасности.

[0262] 5. SM раздает шлюзу (или серверу, или контроллеру, или UE 2) и UE 1 ключ (а именно по меньшей мере одно из: ключ K_{SID_enc} криптографической защиты и ключ K_{SID_int} защиты целостности), полученный на этапе 4. Сообщение может дополнительно включать в себя по меньшей мере одно из: ID сети, ID UE и политику безопасности. В частности, SM может добавить ключ защиты в сообщение установления плоскости пользователя (User Plane Setup) и отправить сообщение установления плоскости пользователя шлюзу (или серверу, или контроллеру, или UE 2) и добавить ключ защиты в сообщение о завершении установления сеанса (Session Setup Complete) и отправить сообщение о завершении установления сеанса пользовательскому оборудованию (UE).

[0263] Дополнительно, на этапе 5 SM может не посылать UE ключ, полученный на этапе 4, а выполнять любую из следующих двух процедур:

[0264] В первой возможной процедуре SM посылает политику безопасности пользовательскому оборудованию (UE). Сообщение может дополнительно включать в себя по меньшей мере одно из: ID сети и ID UE. UE принимает политику безопасности от SM (или управления политикой, или KMS) и вычисляет ключ защиты на основе политики безопасности таким методом, как в приведенных выше вариантах осуществления. Если UE должен использовать случайный параметр при вычислении ключа защиты, случайный параметр может посылаться KMS пользовательскому оборудованию (UE) или может генерироваться UE. Альтернативно, по меньшей мере один из двух одноразовых кодов может использоваться при выведении ключа. Один одноразовый код от KMS (выбранный KMS и напрямую отправленный пользовательскому оборудованию (UE) или отправленный SM пользовательскому оборудованию (UE)), а другой одноразовый код от UE (добавленный в запрос сеанса пользовательским оборудованием (UE)).

[0265] Во второй возможной процедуре SM посылает K_SID и политику безопасности пользовательскому оборудованию (UE), и UE принимает K_SID и политику безопасности от SM (или управления политикой, или KMS) и вычисляет ключ защиты на основе политики безопасности таким же методом, как в приведенных выше вариантах осуществления. Если UE должен использовать случайный параметр при вычислении ключа защиты, случайный параметр может посылаться KMS пользовательскому оборудованию (UE) или может генерироваться UE. Альтернативно, по меньшей мере один из двух одноразовых кодов может использоваться при выведении ключа. Один одноразовый код от KMS (выбранный KMS и напрямую отправленный пользовательскому оборудованию (UE) или отправленный SM пользовательскому оборудованию (UE)), а другой одноразовый код от UE (добавленный в запрос сеанса пользовательским оборудованием (UE)).

[0266] По меньшей мере одно из: ключ K_SID защиты, ключ K_{SID_enc} криптографической защиты и ключ K_{SID_int} защиты целостности, которые UE генерирует или получает от SM, были описаны выше. Кроме того, UE может принимать от KMS (или сетевого элемента управления политикой) политику безопасности и по меньшей мере одно из: ключ K_SID защиты, ключ K_{SID_enc} криптографической защиты и ключ защиты целостности.

[0267] Из приведенного выше процесса можно понять, что фиг. 11 отличается от фиг. 8 - фиг. 10 тем, что после получения K_SID посредством выведения, KMS посылает K_SID сетевому элементу управления сеансами (SM), а затем SM получает ключ K_{SID_enc} криптографической защиты и/или ключ K_{SID_int} защиты целостности посредством выведения на основе K_SID и посылает ключ K_{SID_enc} криптографической защиты и/или ключ K_{SID_int} защиты целостности обоим концам сквозной связи. Другими словами, каждое из двух различных сетевых элементов-устройств выполняет одно выведение ключа.

[0268] Фиг. 12 отличается от фиг. 11 тем, что после получения K_SID посредством выведения, KMS посылает K_SID сетевому элементу управления сеансами (SM), SM затем посылает K_SID шлюзу (или серверу, или контроллеру, или UE 2) и UE, а шлюз (или сервер, или контроллер, или UE 2) и UE 1 получает ключ K_{SID_enc} криптографической защиты и/или ключ K_{SID_int} защиты целостности посредством выведения на основе K_SID.

[0269] Альтернативно, SM может получать ключ K_{SID_enc} криптографической защиты и/или ключ K_{SID_int} защиты целостности посредством выведения на основе K_SID и отправлять K_{SID_enc} и K_{SID_int} пользовательскому оборудованию (UE).

[0270] Альтернативно, SM может отправлять только политику безопасности пользовательскому оборудованию (UE), а UE получать ключ K_{SID_enc} криптографической защиты и/или ключ K_{SID_int} защиты целостности посредством выведения на основе политики безопасности.

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

[0272] Фиг. 13 отличается от фиг. 11 тем, что SM хранит совместно используемый ключ, получает K_SID посредством выведения, а затем получает ключ K_{SID_enc} криптографической защиты и/или ключ K_{SID_int} защиты целостности посредством выведения на основе K_SID и посылает ключ K_{SID_enc} криптографической защиты и/или ключ K_{SID_int} защиты целостности шлюзу (или серверу, или контроллеру, или UE 2) и UE.

[0273] Альтернативно, SM может посылать K_SID и политику безопасности пользовательскому оборудованию (UE), а UE получать ключ K_{SID_enc} криптографической защиты и/или ключ K_{SID_int} защиты целостности посредством выведения.

[0274] Альтернативно, SM может посылать только политику безопасности пользовательскому оборудованию (UE), а UE получать ключ K_{SID_enc} криптографической защиты и/или ключ K_{SID_int} защиты целостности посредством выведения на основе политики безопасности.

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

[0276] Фиг. 14 отличается от фиг. 11 тем, что после получения K_SID посредством выведения SM посылает K_SID шлюзу (или серверу, или контроллеру, или UE 2) и UE, а затем шлюз (или сервер, или контроллер, или UE 2) и UE получают ключ K_{SID_enc} криптографической защиты и/или ключ K_{SID_int} защиты целостности посредством выведения на основе K_SID.

[0277] Альтернативно, SM может получать ключ K_{SID_enc} криптографической защиты и/или ключ K_{SID_int} защиты целостности посредством выведения на основе K_SID и отправлять K_{SID_enc} и K_{SID_int} пользовательскому оборудованию (UE).

[0278] Альтернативно, SM может отправлять только политику безопасности пользовательскому оборудованию (UE), а UE получать ключ K_{SID_enc} криптографической защиты и/или ключ K_{SID_int} защиты целостности посредством выведения на основе политики безопасности.

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

[0280] Следует отметить, что приведенные выше варианты осуществления проиллюстрированы, главным образом, с помощью примеров, в которых KMS или SM выполняют выведение ключа. Кроме того, ключ защиты может быть получен UE, AN, MM, AU, KMS, AAA, SM или сетевым элементом управления политикой посредством выведения.

[0281] Для процесса, в котором MM генерирует ключ защиты посредством выведения, см. процесс, в котором SM генерирует ключ защиты посредством выведения в приведенных выше вариантах осуществления.

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

[0283] Фиг. 15 показывает процесс, в котором сетевой элемент управления политикой генерирует ключ защиты посредством выведения. Процесс включает в себя следующие этапы.

[0284] 1. Сетевой элемент управления политикой генерирует ключ посредством выведения после определения политики безопасности или приема политики безопасности от SM. В частности, сетевой элемент управления политикой может напрямую вычислять по меньшей мере одно из: K_SID, K_{SID_enc} и K_{SID_int} или может сначала вычислять K_SID, а затем вычислять по меньшей мере одно из: K_{SID_enc} и K_{SID_int} на основе K_SID. Сетевой элемент управления политикой может принимать совместно используемый ключ от другого сетевого элемента (KMS, AU, SM, MM или AAA) после выполнения терминалом аутентификации, или инициировать запрос ключа, где запрос защищает ID UE, для получения совместно используемого ключа.

[0285] Для конкретного метода генерации ключа посредством выведения см. приведенные выше варианты осуществления.

[0286] 2. Сетевой элемент управления политикой посылает сгенерированный ключ (и, возможно, политику безопасности) сетевому элементу управления сеансами (SM), а затем SM посылает ключ обоим концам сквозной связи.

[0287] Альтернативно, сетевой элемент управления политикой посылает сгенерированный ключ (и, возможно, политику безопасности) пользовательскому оборудованию (UE) с использованием SM, а затем напрямую посылает сгенерированный ключ другому концу сквозной связи.

[0288] Альтернативно, сетевой элемент управления политикой напрямую посылает ключ защиты (и, возможно, политику безопасности) пользовательскому оборудованию (UE).

[0289] Альтернативно, сетевой элемент управления политикой посылает K_SID сетевому элементу управления сеансами (SM), а затем SM выполняет выведение и посылает K_{SID_enc} и K_{SID_int} обоим концам.

[0290] Когда UE генерирует ключ защиты посредством выведения, UE принимает политику безопасности от SM (или управления политикой, или KMS), и вычисляет ключ защиты на основе политики безопасности таким же методом, как в приведенных выше вариантах осуществления. Если UE должен использовать случайный параметр при вычислении ключа защиты, случайный параметр может посылаться KMS пользовательскому оборудованию (UE) или может генерироваться UE. Альтернативно, по меньшей мере один из двух одноразовых кодов может использоваться при выведении ключа. Один одноразовый код от KMS (выбранный центром управления ключами (KMS) и напрямую посланный пользовательскому оборудованию (UE), или посланный SM пользовательскому оборудованию (UE)), а другой одноразовый код от UE (добавленный к запросу сеанса пользовательским оборудованием (UE)).

[0291] Альтернативно, UE принимает по меньшей мере одно из: ключ K_SID защиты, ключ K_{SID_enc} криптографической защиты и ключ K_{SID_int} защиты целостности от SM (или управления политикой, или KMS) или после приема K_SID UE получает K_{SID_enc} и K_{SID_int} посредством вычисления на основе K_SID.

[0292] Приведенные выше параметры, такие как ID несущей, ID потока, ID временного интервала и ID сеанса, используемый UE при выведении, могут иметься в UE или могут посылаться сетевым элементом (KMS, MM, SM, управлением политикой, AU, шлюзом, AAA и т.п.) пользовательскому оборудованию (UE), например, могут посылаться пользовательскому оборудованию (UE) с использованием сообщения ответа сеанса.

[0293] Учитывая, что приведенная выше политика безопасности включает в себя только требование по обеспечению безопасности, указывающее, требуется ли защита целостности, требуется ли шифрование, или требуются ли защита целостности и шифрование, после получения SMF политики безопасности (может быть получена от PCF или получена SMF через согласование) имеются следующие три вероятных сценария для последующей обработки:

[0294] Вероятный сценарий 1: После получения политики безопасности SMF определяет алгоритм безопасности (в том числе алгоритм шифрования, или алгоритм защиты целостности, или как алгоритм шифрования, так и алгоритм защиты целостности) на основе возможностей безопасности UE и приоритета алгоритма UPF, который хранится в SMF, а затем генерирует ключ защиты (в том числе ключ шифрования, или ключ защиты целостности, или как ключ шифрования, так и ключ защиты целостности) и посылает алгоритм безопасности, который был определен, и сгенерированный ключ узлу плоскости пользователя (UPF). Кроме того, SMF также может отправить алгоритм безопасности, который был определен, пользовательскому оборудованию (UE), так что UE генерирует ключ защиты, соответствующий алгоритму безопасности. SMF также может отправить политику безопасности пользовательскому оборудованию (UE).

[0295] Вероятный сценарий 2: SMF вычисляет ключ K_SID и посылает политику безопасности и K_SID узлу плоскости пользователя (UPF). Аналогично, UPF также может принять возможности безопасности пользовательского оборудования (UE) с использованием SMF. UPF определяет алгоритм безопасности (в том числе алгоритм шифрования, или алгоритм защиты целостности, или как алгоритм шифрования, так и алгоритм защиты целостности) на основе возможностей безопасности UE и приоритета алгоритма, а затем генерирует ключ защиты (в том числе ключ шифрования, или ключ защиты целостности, или как ключ шифрования, так и ключ защиты целостности). UPF посылает алгоритм безопасности объекту управления сеансами (SMF), а SMF посылает алгоритм безопасности пользовательскому оборудованию (UE), так что UE генерирует ключ защиты, соответствующий алгоритму безопасности. Альтернативно, UPF может напрямую посылать алгоритм безопасности пользовательскому оборудованию (UE), так что UE генерирует ключ защиты, соответствующий алгоритму безопасности.

[0296] Вероятный сценарий 3: После получения политики безопасности SMF посылает политику безопасности AN, так что AN определяет алгоритм обеспечения безопасности между UE и AN на основе политики безопасности, возможностей безопасности UE и списка приоритетов алгоритма AN, а затем AN посылает алгоритм обеспечения безопасности UE, так что UE генерирует ключ защиты, соответствующий алгоритму безопасности.

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

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

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

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

[0301] Нет никакой конкретной последовательности между процедурой согласования ключа и процедурой согласования политики безопасности. Например, ключ K_SID может генерироваться до, во время или после установления сеанса (несущей, потока или интервала). Ключ криптографической защиты и/или защиты целостности может генерироваться в любой момент времени после генерации K_SID.

[0302] Все процедуры, показанные на фиг. 4, фиг. 5 и фиг. 7, являются процессом определения политики безопасности или процессом конфигурирования ключа, когда UE 1 посылает запрос сеанса, запрос несущей, запрос потока или запрос временного интервала сети оператора связи, и сеть оператора связи одобряет запрос. Следует отметить, что если сеть оператора связи отклоняет запрос сеанса, запрос несущей, запрос потока или запрос временного интервала UE 1, сеть оператора связи посылает сообщение об отклонении UE 1.

[0303] В процедурах, показанных на фиг. 2 - фиг. 9, используемые требования по обеспечению безопасности основаны на случае, в котором оконечная точка обеспечения безопасности является узлом плоскости пользователя (User plane function, UPF). Однако, оконечная точка обеспечения безопасности альтернативно может быть точкой ветвления или ULCL.

[0304] Оконечная точка обеспечения безопасности может определяться сетевым элементом управлением мобильностью (Mobility Management, MM), сетевым элементом управления сеансами (Session Management, SM), контроллером аутентификации услуги (Authentication Server Function (функция аутентификации сервера), AUSF), сетевым элементом функции привязки безопасности (Security Anchor Function, SEAF), узлом управления мобильностью (Mobility Management Entity, MME), сервером абонентов (Home Subscriber Server, HSS), центром аутентификации (Authentication Center, AuC), сетевым элементом функции хранения и обработки учетных данных (Authentication Credential Repository and Processing Function, ARPF), сетевым элементом управления контекстом защиты (Security Context Management Function, SCMF), сетевым элементом функции управления доступом и мобильностью (Access and Mobility management Function, AMF), узлом доступа (сеть доступа, Access network, AN), узлом плоскости пользователя (User plane function, UPF), блоком аутентификации в сети (англ.: Control Plane-Authentication Unit (блок аутентификации плоскости управления), CP-AU для краткости) или модулем определения политики безопасности.

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

[0306] В процедурах, показанных на фиг. 2 - фиг. 9, после того, как UE 1 посылает запрос подключения, или после успешного выполнения двусторонней аутентификации, или в процессе, в котором UE 1 устанавливает сеанс (до того, как UE 1 посылает запрос сеанса, или после того, как UE 1 посылает запрос сеанса), модуль определения политики безопасности может дополнительно выполнять следующие этапы: определения оконечной точки обеспечения безопасности; и если оконечная точка обеспечения безопасности является UPF, выполнения этапа после двусторонней аутентификации или после того, как UE 1 посылает запрос сеанса, в процедурах, показанных на фиг. 2 - фиг. 9, или если оконечная точка обеспечения безопасности является AN, замены требования 3 по обеспечению безопасности или требования UE 2 по обеспечению безопасности (случай требования 4 по обеспечению безопасности) в процедурах, показанных на фиг. 2 - фиг. 9 на требование AN по обеспечению безопасности. Метод получения требования AN по обеспечению безопасности может иметь следующий вид: на основе приведенных выше вариантов осуществления после приема сообщения запроса UE 1 AN посылает сети как сообщение запроса UE 1, так и требование AN по обеспечению безопасности.

[0307] Фиг. 16 (a) и фиг. 16 (b) являются сценариями ветвления. В этих сценариях модуль определения политики безопасности должен определить, является ли оконечная точка обеспечения безопасности точкой ветвления или UPF. Если оконечная точка обеспечения безопасности является UPF, выполняется этап после двусторонней аутентификации или после того, как UE 1 посылает запрос сеанса, в процедурах, показанных на фиг. 2 - фиг. 9. Если оконечная точка обеспечения безопасности является точкой ветвления, требование 3 по обеспечению безопасности или требование по обеспечению безопасности UE 2 (случай требования 4 по обеспечению безопасности) в процедурах, показанных на фиг. 2 - фиг. 9, заменяется требованием по обеспечению безопасности точки ветвления.

[0308] Фиг. 17 показывает сценарий, в котором линией связи сеанса является UE-AN-UPF (функция классификатора данных восходящей линии связи (uplink data classifier function), функциональность классификатора восходящей линии связи (uplink classifier functionality), ULCL)-UPF (привязка). В этом сценарии модуль определения политики безопасности должен определить, является ли оконечной точкой обеспечения безопасности UPF (ULCL) или UPF (привязка). Если оконечной точкой обеспечения безопасности является UPF (привязка), выполняется этап после двусторонней аутентификации или после того, как UE 1 посылает запрос сеанса, в процедурах, показанных на фиг. 2 - фиг. 9. Если оконечной точкой обеспечения безопасности является ULCL, требование 3 по обеспечению безопасности или требование по обеспечению безопасности UE 2 (случай требования 4 по обеспечению безопасности) в процедурах, показанных на фиг. 2 - фиг. 9, заменяется требованием по обеспечению безопасности ULCL.

[0309] В случае роуминга с домашней маршрутизацией, показанном на фиг. 18, маршрут плоскости пользователя имеет вид UE-AN-UPF (VPLMN)-UPF (HPLMN). В этом случае оконечной точкой сквозного обеспечения безопасности может быть UPF (гостевой наземной сети мобильной связи общего пользования (visited public land mobile communications network, visited public land mobile network, VPLMN)) или UPF (домашней наземной сети мобильной связи общего пользования (home public land mobile communications network, home public land mobile network, HPLMN)). В этом сценарии при определении политики безопасности должно быть определено, является ли оконечной точкой обеспечения безопасности UPF (VPLMN) или UPF (HPLMN). Если оконечной точкой обеспечения безопасности является UPF (VPLMN), требование 3 по обеспечению безопасности является требованием по обеспечению безопасности шлюза в VPLMN. Если оконечной точкой обеспечения безопасности является UPF (HPLMN), требование 3 по обеспечению безопасности является требованием по обеспечению безопасности шлюза в HPLMN.

[0310] Модуль определения политики безопасности может определить на основе конфигурационной информации или политики узла UE 1, которая принимается от другого функционального сетевого элемента, такого как HSS, AUSF, ARPF, AMF, SEAF, SCMF, SM или AuC, или на основе конфигурационной информации, или политики узла UE, или сеанса (или потока, несущей, или интервала), который получается из локального хранилища, и на основе конфигурационной информации UE или сеанса (или потока, несущей, или интервала), является ли оконечной точкой обеспечения безопасности AN, точка ветвления, ULCL или UPF. Политика узла может быть политикой узла каждого UE, может быть политикой узла для этого типа услуги, может быть политикой узла для этого типа временного интервала, или может быть политикой узла для этого типа данных. Кроме того, альтернативно, модуль определения политики безопасности может определять оконечную точку обеспечения безопасности на основе требования по обеспечению безопасности услуги, требования серверной стороны по обеспечению безопасности, типа услуги, типа временного интервала или политики разбиения на временные интервалы.

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

[0312] Модуль определения политики безопасности временного интервала может быть расположен в сетевом элементе управления мобильностью (Mobility Management, MM), сетевом элементе управления сеансами (Session Management, SM), контроллере аутентификации услуги (Authentication Server Function (функция аутентификации сервера), AUSF), сетевом элементе функции привязки безопасности (Security Anchor Function, SEAF), узле управления мобильностью (Mobility Management Entity, MME), сервере абонентов (Home Subscriber Server, HSS), центре аутентификации (Authentication Center, AuC), сетевом элементе функции хранения и обработки учетных данных (Authentication Credential Repository and Processing Function, ARPF), сетевом элементе управления контекстом защиты (Security Context Management Function, SCMF), сетевом элементе функции управления доступом и мобильностью (Access and Mobility management Function, AMF), узле AN, узле UPF, блоке аутентификации в сети (Control Plane-Authentication Unit (блок аутентификации плоскости управления), CP-AU) или модуле определения политики безопасности.

[0313] Конкретные процедуры определения политики безопасности могут быть классифицированы на следующие три случая:

[0314] Перед установлением сеанса и после завершения аутентификации модуль определения политики безопасности временного интервала (например, может быть эквивалентен приведенному выше модулю определения политики безопасности) определяет политику безопасности временного интервала таким же методом, как в приведенных выше вариантах осуществления, а именно, на основе по меньшей мере одного из: возможностей безопасности UE 1, требования услуги по обеспечению безопасности, возможностей безопасности функционального сетевого элемента во временном интервале, возможностей безопасности UE 1, предварительно заданных в сети, и требования по обеспечению безопасности на стороне сервера приложений. Возможности безопасности функционального сетевого элемента во временном интервале могут быть получены от HSS, AUSF, ARPF, AMF, SEAF, SCMF, SM, AuC и т.п.

[0315] Во время установления сеанса политика безопасности временного интервала определяется методом, аналогичным используемому выше.

[0316] После установления сеанса определяется политика безопасности временного интервала. Согласование политики безопасности и согласование ключа не включены в процесс установления сеанса.

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

[0318] В процедуре конфигурирования ключа в этом варианте осуществления этой заявки ключ защиты сеанса может быть сконфигурирован для UE и шлюза (или сервера DN, или UE 2). Таким образом, реализована сквозная защита сеанса на основе 5G архитектуры мобильной связи. Реализована более высокая степень безопасности по сравнению с существующим методом шифрования на основе сегментов.

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

[0320] Фиг. 19 показывает сетевой элемент SM в соответствии с одним вариантом осуществления этой заявки. Сетевой элемент SM включает в себя компонент связи и процессор и может дополнительно включать в себя память. Компонент связи выполнен с возможностью приема запроса на сквозную связь. Процессор выполнен с возможностью получения политики безопасности. Компонент связи дополнительно выполнен с возможностью: отправки политики безопасности и/или ключа защиты пользовательскому оборудованию; и отправки политики безопасности и/или ключа защиты устройству на другом конце сквозной связи. Для конкретных реализаций функций компонента связи и процессора см. фиг. 2 - фиг. 15. Подробности не будут описываться здесь повторно.

[0321] Вариант осуществления этой заявки дополнительно раскрывает KMS, MM, HSS и сетевой элемент управления политикой. Для конкретных реализаций функций компонента связи и процессора, которые включены в конкретную структуру, см. фиг. 2 - фиг. 15. Подробности не будут описываться здесь повторно.

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

[0323] Компонент связи выполнен с возможностью отправки запроса и приема ответа. Запрос включает в себя идентификатор пользовательского оборудования. Ответ содержит политику безопасности.

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

[0325] Для конкретных реализаций функций компонента связи и процессора см. фиг. 2 - фиг. 15. Подробности не будут описываться здесь повторно.

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

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