СПОСОБ И СИСТЕМА ЗАЩИЩЕННОГО ДОСТУПА К HNB ИЛИ HeNB И ЭЛЕМЕНТ БАЗОВОЙ СЕТИ
METHOD AND SYSTEM FOR SECURE ACCESS TO HNB OR HeNB AND CORE NETWORK ELEMENT

Область техники
Настоящее изобретение относится к технологии защищенного доступа к исходному (развитому) узлу В (H(e)NB) и, в частности, к способу и системе защищенного доступа к H(e)NB и к элементу базовой сети.
Предпосылки изобретения
Развитая пакетная система (EPS), предоставляемая проектом партнерства 3-го поколения (3GPP), состоит из развитой универсальной сети наземного радиодоступа (E-UTRAN), узла управления мобильностью (ММЕ), обслуживающего шлюза (S-GW), шлюза пакетной сети передачи данных (P-GW или PDN GW), сервера домашних абонентов (HSS) и сервера аутентификации, авторизации и учета (AAA).
Когда H(e)NB получает доступ к развитому пакетному ядру (ЕРС) для обеспечения безопасности, шлюз безопасности (SeGW) вводится в развитую базовую сеть, и H(e)NB устанавливает IPSec-туннель со шлюзом безопасности вначале перед соединением с оборудованием базовой сети. Передаваемые данные плоскости управления и данные плоскости пользователя между H(e)NB и оборудованием базовой сети зашифрованы этим IPSec-туннелем. На фиг. 1 представлена диаграмма структуры системы H(e)NB, получающего доступ к базовой сети. Как показано на фиг. 1, эта структура одновременно поддерживает традиционный стандарт получения доступа GERAN/UTRAN и стандарт "долгосрочное развитие" (LTE); при этом исходный узел В (HNB) представляет собой исходную базовую станцию, поддерживающую стандарт GERAN/UTRAN, а исходный eNodeB (HeNB) представляет собой исходную базовую станцию, поддерживающую LTE. Шлюз исходной базовой станции (шлюз исходного узла В, HNB GW) является обязательным, если HNB принят для получения доступа. HNB необходимо зарегистрироваться в HNB GW, когда HNB включен. Шлюз развитой исходной базовой станции (шлюз исходного eNodeB, HeNB GW) является факультативным. Когда HeNB GW развернут, HeNB регистрируется в HeNB GW; когда HeNB GW не развернут, HeNB записывается в ММЕ.
Согласно протоколу 3GPP, когда UE получает доступ с H(e)NB (то есть, HNB или HeNB), ММЕ или обслуживающий узел SGSN поддержки GPRS (SGSN) или HNB GW выполняет контроль доступа UE. Когда UE подключается через H(e)NB, если UE и сеть поддерживают закрытую группу абонентов (CSG), H(e)NB передает уведомление об идентификаторе CSG (CSG ID), поддерживаемом им самим, в SGSN или ММЕ. SGSN или ММЕ принимает решение, разрешить ли пользователю доступ с этого H(e)NB в соответствии с данными о подписке пользователя, полученными от HSS. Когда UE подключается через HNB и если UE или сеть не поддерживает CSG, HNB GW принимает решение, разрешить ли этому UE доступ с этого HNB в соответствии со списком UE IMSI, разрешенным HNB и локально сконфигурированным.
В описанном выше процессе получения доступа UE через H(e)NB все релевантные сообщения защищены защищенным туннелем между H(e)NB и SeGW. H(e)NB устанавливает защищенный туннель с SeGW и аутентифицирует друг с другом при включении питания, поэтому H(e)NB является правдоподобным с точки зрения SeGW. Однако релевантный протокол не может гарантировать, что идентификатор, отправленный на MME/SGSN/HNB GW посредством H(e)NB, одинаков для идентификатора при взаимной аутентификации с SeGW. К тому же, во множестве сцен H(e)NB использует идентификатор в MME/SGSN/HNB GW, который отличается от идентификатора при взаимной аутентификации с SeGW. В соответствии с текущим протоколом SeGW не отвечает за аутентификацию идентификатора, который используется H(e)NB в MME/SGSN/HNB GW.
Следовательно, в соответствии с релевантным протоколом H(e)NB может впоследствии неправомерно использовать идентификатор другой группы при соединении с MME/SGSN/H(e)NB GW. Например, HeNB1 использует истинный идентификатор (этот идентификатор основан на сертификате или на модуле предоставляющей хостинг стороны (НРМ)) для установки в первую очередь IPSec-туннеля и взаимной аутентификации с SeGW; когда UE получает доступ с HeNB1, HeNB1 отправляет HeNB ID, относящийся к HeNB2, и CSG ID, поддерживаемый посредством HeNB2, на ММЕ. В соответствии с CSG ID, относящемуся к HeNB2, доступ UE разрешен; однако доступ UE не будет разрешен, если он будет основан на CSG ID, поддерживаемом посредством HeNB1. В приведенном выше примере HeNB1 неправомерно использует идентификатор другой группы, тем самым позволяя пользователю, который изначально не имеет доступа, получить доступ к сети, тем самым нарушая безопасность сети.
Для решения такой проблемы некоторые предлагают способ, при котором между SeGW и MME/H(e)NB GW добавляют новый интерфейс, и SeGW отправляет отношение ассоциации между H(e)NB ID и внутренним IP адресом H(e)NB на MME/H(e)NB GW для аутентификации идентификатора H(e)NB в базовой сети (то есть идентификатора, используемого в MME/H(e)NB GW). Однако этот способ характеризуется множеством недостатков, в частности: отношение ассоциации между H(e)NB ID и внутренним IP адресом H(e)NB может инициироваться только посредством IPSec сообщения, отправляемого на MME//H(e)NB GW, когда H(e)NB включен, и SeGW должен выбрать соответствующий MME//H(e)NB GW для отправки этого отношения ассоциации, и необходимо гарантировать, что H(e)NB выберет тот же ММЕ или H(e)NB GW, когда H(e)NB записан, поэтому необходимо гарантировать, что H(e)NB выберет тот же ММЕ или H(e)NB GW при конкретной реализации, что, несомненно, повышает сложность осуществления. При этом если H(e)NB не выбирает отправку ММЕ или H(e)NB GW с собственным идентификатором, когда он изначально включен, этот способ не сработает. В соответствии с релевантным протоколом H(e)NB выбирает ММЕ или H(e)NB GW согласно информации о конфигурации H(e)MS, но между SeGW и H(e)MS нет интерфейса, слишком сложно гарантировать, что ММЕ и H(e)NB GW, выбранные посредством SeGW, такие же, как и H(e)NB и ММЕ, выбранные посредством H(e)NB GW. При такой схеме считается, что ММЕ и H(e)NB GW являются сервером аутентификации H(e)NB, однако в соответствии с релевантным протоколом аутентификация, основанная на НРМ модуле, является факультативной, поэтому аутентификация H(e)NB может и не выполняться для AAA-сервера, что делает эту схему неподходящей для всех сцен.
Краткое изложение сущности изобретения
С учетом сказанного выше основной целью вариантов осуществления настоящего изобретения является предоставление способа и системы защищенного доступа к исходному (развитому) узлу В (H(e)NB), которые могут предотвратить ситуацию, когда недопустимый H(e)NB выдает себя за допустимый H(e)NB для доступа к базовой сети и для предоставления услуг для оборудования пользователя.
Для достижения описанной выше цели техническое решение согласно вариантам осуществления настоящего изобретения осуществляется следующим образом.
Способ защищенного доступа к исходному (развитому) узлу В (H(e)NB) включает:
подписание шлюзом безопасности (SeGW) информации об идентификаторе H(e)NB и отправку цифровой подписи H(e)NB на H(e)NB;
отправку посредством H(e)NB цифровой подписи и информации об идентификаторе H(e)NB на элемент базовой сети;
выполнение элементом базовой сети проверки правильности цифровой подписи и информации об идентификаторе H(e)NB.
Предпочтительно этап подписания шлюзом безопасности (SeGW) цифровой подписи для информации об идентификаторе H(e)NB включает:
получение посредством SeGW при выполнении аутентификации идентификатора на H(e)NB информации об идентификаторе H(e)NB и подписание цифровой подписи для информации об идентификаторе H(e)NB.
Предпочтительно этап отправки посредством H(e)NB информации об идентификаторе H(e)NB на элемент базовой сети включает:
при регистрации H(e)NB отправку посредством H(e)NB цифровой подписи и информации об идентификаторе H(e)NB на элемент базовой сети.
Предпочтительно этап отправки посредством H(e)NB цифровой подписи и информации об идентификаторе H(e)NB на элемент базовой сети включает:
когда пользовательское оборудование (UE) регистрируется посредством H(e)NB, отправку посредством H(e)NB цифровой подписи и информации об идентификаторе H(e)NB на элемент базовой сети.
Предпочтительно SeGW использует частный ключ SeGW для подписи цифровой подписи для информации об идентификаторе H(e)NB;
соответственно, элемент базовой сети выполняет проверку правильности цифровой подписи и информации об идентификаторе H(e)NB посредством открытого ключа SeGW.
Предпочтительно SeGW использует динамический ключ сеанса для подписи цифровой подписи для информации об идентификаторе H(e)NB; и
способ дополнительно включает: отправку уведомления посредством SeGW на сервер домашних абонентов (HSS)/сервер аутентификации, авторизации и учета (AAA) динамического ключа сеанса и хранение HSS/AAA сервером динамического ключа сеанса.
Предпочтительно этап выполнения элементом базовой сети проверки правильности цифровой подписи и информации об идентификаторе H(e)NB включает:
получение элементом базовой сети от AAA/HSS динамического ключа сеанса для подписи информации об идентификаторе H(e)NB и выполнение проверки информации об идентификаторе H(e)NB с помощью динамического ключа сеанса.
Предпочтительно информация об идентификаторе H(e)NB представляет собой H(e)NB ID и внутренний IP адрес H(e)NB, или представляет собой ID закрытой группы абонентов (CSG) и внутренний IP адрес H(e)NB, или представляет собой H(e)NB ID, CSG ID и внутренний IP адрес H(e)NB.
Предпочтительно способ дополнительно включает:
после успешной проверки информации H(e)NB и цифровой подписи элементом базовой сети сохранение элементом базовой сети информации о H(e)NB.
Предпочтительно элемент базовой сети представляет собой H(e)NB GW или узел управления мобильностью (ММЕ).
Предпочтительно элемент базовой сети представляет собой ММЕ, обслуживающий узел поддержки GPRS (SGSN) или мобильный коммутационный центр (MSC).
Предпочтительно когда UE получает доступ посредством H(e)NB, после проверки элементом базовой сети правильности информации об идентификаторе H(e)NB элемент базовой сети отправляет информацию об идентификаторе H(e)NB на ММЕ, или SGSN, или MSC, и ММЕ, или SGSN, или MSC получает информацию о CSG ID, поддерживаемую H(e)NB, и выполняет контроль доступа на UE в соответствии с информацией о CSG ID; при этом ММЕ, или SGSN, или MSC получает информацию о CSG ID из информации H(e)NB, или получает информацию о CSG ID из HSS/AAA сервер.
Предпочтительно когда UE получает доступ посредством H(e)NB, после проверки элементом базовой сети правильности информации об идентификаторе H(e)NB элемент базовой сети получает информацию о CSG ID, поддерживаемую H(e)NB, и выполняет контроль доступа на UE в соответствии с информацией о CSG ID; при этом элемент базовой сети получает информацию о CSG ID из информации H(e)NB, или получает информацию о CSG ID из HSS/AAA сервер.
Предпочтительно элемент базовой сети получает открытый ключ SeGW из сконфигурированного сертификата SeGW, или элемент базовой сети получает открытый ключ SeGW из сертификата, отправленного из H(e)NB на элемент базовой сети.
Предпочтительно SeGW отправляет цифровую подпись на H(e)NB путем расширения полезной нагрузки конфигурации (CP) IKEv2.
Предпочтительно SeGW отправляет информацию об идентификаторе H(e)NB на H(e)NB путем расширения полезной нагрузки конфигурации (CP) IKEv2.
Способ защищенного доступа к исходному (развитому) узлу В (H(e)NB) включает: при регистрации H(e)NB в элементе базовой сети получение элементом базовой сети информации об идентификаторе H(e)NB через интерфейс связи, сконфигурированный между элементом базовой сети и шлюзом безопасности (SeGW), выполнение проверки правильности информации об идентификаторе, сообщаемой посредством H(e)NB, и после прохождения проверки прием регистрации H(e)NB.
Предпочтительно элемент базовой сети представляет собой H(e)NB GW; когда H(e)NB GW не сконфигурирован, элемент базовой сети представляет собой узел управления мобильностью (ММЕ).
Система защищенного доступа к исходному (развитому) узлу В (H(e)NB) содержит шлюз безопасности (SeGW) и элемент базовой сети; при этом
SeGW сконфигурирован для: подписи информации об идентификаторе H(e)NB и отправки цифровой подписи вместе с информацией об идентификаторе H(e)NB на H(e)NB;
элемент базовой сети сконфигурирован для: получения информации об идентификаторе и цифровой подписи, отправленной посредством H(e)NB, и выполнения проверки правильности цифровой подписи и информации об идентификаторе H(e)NB.
Предпочтительно SeGW сконфигурирован для использования частного ключа SeGW для подписания цифровой подписи для информации об идентификаторе H(e)NB;
соответственно, элемент базовой сети сконфигурирован для проверки правильности цифровой подписи и информации об идентификаторе H(e)NB посредством открытого ключа SeGW.
Предпочтительно SeGW сконфигурирован для использования динамического ключа сеанса для подписи цифровой подписи для информации об идентификаторе H(e)NB; и
отправки уведомления на сервер домашних абонентов (HSS)/сервер аутентификации, авторизации и учета (AAA) динамического ключа сеанса.
Предпочтительно элемент базовой сети сконфигурирован для: получения от AAA/HSS динамического ключа сеанса для цифровой подписи информации об идентификаторе H(e)NB и проверки информации об идентификаторе H(e)NB с помощью динамического ключа сеанса.
Предпочтительно информация об идентификаторе H(e)NB представляет собой H(e)NB ID и внутренний IP адрес H(e)NB, или представляет собой ID закрытой группы абонентов (CSG) и внутренний IP адрес H(e)NB, или представляет собой H(e)NB ID, CSG ID и внутренний IP адрес H(e)NB; и
элемент базовой сети представляет собой узел управления мобильностью (ММЕ), обслуживающий узел поддержки GPRS (SGSN) или H(e)NB GW.
Предпочтительно SeGW сконфигурирован для отправки информации об идентификаторе H(e)NB на H(e)NB.
Элемент базовой сети сконфигурирован для:
получения информация об идентификаторе, отправленной посредством исходного (развитого) узла В (H(e)NB), и цифровой подписи, подписанной для информации об идентификаторе посредством шлюза безопасности (SeGW), и выполнения проверки правильности информации об идентификаторе и цифровой подписи.
Элемент базовой сети сконфигурирован для:
получения информации об идентификаторе исходного (развитого) узла В (H(e)NB), выполняющего аутентификацию идентификатора через интерфейс связи между элементом базовой сети и шлюзом безопасности (SeGW), выполнения проверки правильности информации об идентификаторе, сообщаемой посредством H(e)NB, и приема регистрации H(e)NB после прохождения проверки.
Решение согласно вариантам осуществления настоящего изобретения позволяет устранить регистрацию недопустимого H(e)NB непосредственно в элементе базовой сети и реализует доступ к услугам UE, тем самым сохраняя защищенность сети.
Краткое описание графических материалов
На фиг. 1 показана диаграмма структуры системы H(e)NB, получающего доступ к базовой сети;
на фиг. 2 показана блок-схема способа защищенного доступа к исходному (развитому) узлу В (H(e)NB) в соответствии с первым вариантом осуществления настоящего изобретения;
на фиг. 3 показана блок-схема способа защищенного доступа к исходному (развитому) узлу В (H(e)NB) в соответствии со вторым вариантом осуществления настоящего изобретения;
на фиг. 4 показана блок-схема способа защищенного доступа к исходному (развитому) узлу В (H(e)NB) в соответствии с третьим вариантом осуществления настоящего изобретения;
на фиг. 5 показана блок-схема способа защищенного доступа к исходному (развитому) узлу В (H(e)NB) в соответствии с четвертым вариантом осуществления настоящего изобретения;
на фиг. 6 показана структурная схема системы защищенного доступа к исходному (развитому) узлу В (H(e)NB) в соответствии с вариантом осуществления настоящего изобретения;
на фиг. 7 показана блок-схема способа защищенного доступа к исходному (развитому) узлу В (H(e)NB) в соответствии с пятым вариантом осуществления настоящего изобретения.
Предпочтительные варианты осуществления изобретения
Согласно вариантам осуществления настоящего изобретения шлюз безопасности (SeGW) подписывает цифровую подпись для информации об идентификаторе исходного (развитого) узла В (H(e)NB), когда SeGW выполняет аутентификацию идентификатора на H(e)NB, и отправляет цифровую подпись на H(e)NB; H(e)NB отправляет собственную информацию об идентификаторе и цифровую подпись на элемент базовой сети при подключении UE, или обновлении отслеживаемой области, или при обновлении маршрутизации; и элемент базовой сети выполняет проверку правильности информации об идентификаторе и цифровой подписи H(e)NB и выполняет контроль доступа на UE после завершения проверки. Или же, интерфейс связи установлен между SeGW и элементом базовой сети, элемент базовой сети получает информацию об идентификаторе H(e)NB от SeGW, при получении запроса на регистрацию от H(e)NB, и выполняет аутентификацию идентификатора на H(e)NB, который запрашивает регистрацию.
Первый вариант осуществления
На фиг. 2 показана блок-схема способа защищенного доступа к H(e)NB в соответствии с одним вариантом осуществления настоящего изобретения; поскольку H(e)NB может подвергаться атакам, базовая сеть не может доверять идентификатору, предоставляемому самим H(e)NB. С учетом того, что SeGW является надежным объектом обеспечения безопасности, следовательно, настоящее изобретение предусматривает, что SeGW подписывает цифровую подпись для идентификатора H(e)NB и отправляет эту цифровую подпись на H(e)NB. H(e)NB отправляет цифровую подпись, подписанную SeGW, и информацию об идентификаторе на элемент базовой сети для выполнения аутентификации идентификатора. Как показано на фиг. 2, приведенный в примере способ защищенного доступа H(e)NB включает следующие этапы.
На этапе 201 SeGW подписывает цифровую подпись для информации об идентификаторе H(e)NB.
Информация об идентификаторе H(e)NB содержит H(e)NB ID, и/или CSG ID, и/или другие идентификаторы. Для проверки, была ли эта информация об идентификаторе H(e)NB с цифровой подписью отправлена на самом деле посредством SeGW на определенный H(e)NB, SeGW содержит внутренний IP адрес H(e)NB в этой информации об идентификаторе H(e)NB. Внутренний IP адрес H(e)NB представляет собой IP адрес, назначаемый для H(e)NB посредством SeGW при установке IPSec-туннеля. H(e)NB принимает этот внутренний IP адрес для соединения с элементом базовой сети, и этот внутренний IP адрес включен в заголовок внутреннего IP пакета сообщения IPSec-туннеля.
SeGW может подписывать цифровую подпись для информации об идентификаторе H(e)NB с помощью частного ключа SeGW, а также может подписывать цифровую подпись для информации об идентификаторе H(e)NB с помощью ключа сеанса для информации об идентификаторе H(e)NB.
На этапе 202 SeGW отправляет цифровую подпись на H(e)NB, а также может отправлять информацию об идентификаторе на H(e)NB.
На этапе 203 H(e)NB отправляет описанную выше цифровую подпись и информацию об идентификаторе H(e)NB на элемент базовой сети (то есть H(e)NB GW, ММЕ или SGSN). H(e)NB может отправлять описанную выше информацию при регистрации или отправке описанной выше информации вместе с релевантным сообщением UE, когда UE получает доступ. При отправке описанной выше информации во время регистрации эта информация будет отправляться на H(e)NB GW, и если H(e)NB GW не развернут, он отправляется на ММЕ; при его отправке вместе с релевантным сообщением UE, когда UE получает доступ, эта информация будет отправлена на ММЕ (для EUTRAN), или SGSN (для UTRAN или GERAN), или MSC.
На этапе 204 элемент базовой сети проверяет цифровую подпись для информации об идентификаторе H(e)NB.
Когда SeGW подписывает цифровую подпись для информации об идентификаторе H(e)NB с помощью частного ключа, элемент базовой сети (то есть ММЕ, SGSN или H(e)NB GW) проверяет цифровую подпись с помощью открытого ключа SeGW. Когда SeGW подписывает цифровую подпись для информации об идентификаторе H(e)NB с помощью ключа сеанса, элемент базовой сети должен использовать тот же ключ сеанса для проверки цифровой подписи.
Согласно этому варианту осуществления существует два различных способа проверки согласно различным местоположениям для проверки информации об идентификаторе H(e)NB соответственно: проверка информации об идентификаторе H(e)NB при регистрации H(e)NB; или проверка идентификатора H(e)NB при получении доступа UE.
Если информация об идентификаторе H(e)NB проверяется при регистрации H(e)NB, тогда объектом, который проверяет идентификатор H(e)NB, будет H(e)NB GW или ММЕ (если H(e)NB GW не развернут). Поскольку между H(e)NB GW и AAA/HSS интерфейса нет, такая схема подходит для использования режима цифровой подписи на основе открытого и частного ключа.
Если информация об идентификаторе H(e)NB проверяется при получении доступа UE, тогда объектом, который проверяет идентификатор H(e)NB, является ММЕ (для EUTRAN) или SGSN (для GERAN/UTRAN). Такая схема может принимать режим цифровой подписи на основе открытого и частного ключа или режим цифровой подписи на основе динамического ключа сеанса.
Описанный выше способ дополнительно описан совместно с характерными процедурами.
Второй вариант осуществления
На фиг. 3 показана блок-схема способа защищенного доступа H(e)NB в соответствии со вторым вариантом осуществления настоящего изобретения. Приведенным примером является способ для H(e)NB GW или ММЕ для проверки цифровой подписи информации об идентификаторе H(e)NB при регистрации H(e)NB. Как показано на фиг. 3, приведенный в примере способ защищенного доступа H(e)NB включает следующие этапы.
На этапе 301 H(e)NB включен. H(e)NB получает доступ к локальной сети и получает информацию о конфигурации IP адреса от локальной сети.
На этапе 302 H(e)NB инициирует IKEv2 согласование с SeGW. Этот процесс включает взаимную аутентификацию H(e)NB и SeGW, согласование ассоциации защиты, распределение посредством SeGW внутреннего IP адреса для H(e)NB и т.д.
На этапе 303 SeGW получает информацию об идентификаторе H(e)NB, используемого для передачи данных по базовой сети, и эта информация содержит H(e)NB ID и/или CSG ID и т.д. SeGW подписывает информацию об идентификаторе H(e)NB, и специальный алгоритм цифровой подписи выглядит следующим образом:
X = Алгоритм 1 (информация об идентификаторе H(e)NB | IP адрес H(e)NB) [А].
В формуле [А] "|" означает расположение информации каскадом. Когда информация об идентификаторе H(e)NB содержит несколько фрагментов информации, SeGW располагает каскадом несколько фрагментов информации, то есть соединяет несколько фрагментов информации последовательно. Например, когда информация об идентификаторе представляет собой H(e)NB ID и CSG ID, информация об идентификаторе H(e)NB в приведенной выше формуле представляет собой H(e)NB ID | CSG ID.
Алгоритм 1 представляет собой однонаправленный алгоритм хеширования, и настоящее изобретение не предусматривает конкретный алгоритм. Алгоритм предназначен для превращения длинной строки символов в длину, подходящую для алгоритма цифровой подписи. В качестве примера, простой однонаправленный алгоритм хеширования представляет собой MD5 алгоритм.
Цифровая подпись = Алгоритм цифровой подписи (X, ключ цифровой подписи) [В].
Настоящее изобретение не предусматривает конкретный алгоритм цифровой подписи, при этом алгоритм цифровой подписи может относиться к любому алгоритму цифровой подписи из уровня техники; например, общий RSA алгоритм можно использовать в качестве алгоритма цифровой подписи в соответствии с настоящим изобретением.
В приведенном примере ключ цифровой подписи является частным ключом SeGW.
На этапе 304 SeGW отправляет цифровую подпись на H(e)NB; альтернативно SeGW может отправлять вместе информацию об идентификаторе H(e)NB на H(e)NB. Если информация об идентификаторе H(e)NB (например, CSG ID, H(e)NB ID) не отправлена на H(e)NB через SeGW, H(e)NB может получить ее от H(e)MS или фиксированно конфигурирует ее на H(e)NB. Если для H(e)NB необходимо назначить IP адрес, SeGW также отправляет IP адрес на H(e)NB. Цифровую подпись и информацию об идентификаторе H(e)NB можно отправить посредством расширения протокола IKEv2, например, можно расширить полезную нагрузку конфигурации (CP) IKEv2, для вложения цифровой подписи и информации об идентификаторе H(e)NB в полезную нагрузку конфигурации для отправки на H(e)NB.
На этапе 305 согласование IKEv2 завершается. Между H(e)NB и SeGW устанавливается защищенный IPSec-туннель.
На этапе 306 H(e)NB получает параметр конфигурации от H(e)MS.
На этапе 307, когда сеть развертывает H(e)NB GW, H(e)NB отправляет сообщение с запросом на регистрацию на H(e)NB GW, и H(e)NB отправляет информацию об идентификаторе H(e)NB и его цифровую подпись на H(e)NB GW в этом сообщении.
На этапе 308 H(e)NB GW проверяет цифровую подпись и информацию об идентификаторе H(e)NB. Способ проверки заключается в следующем:
H(e)NB GW дешифрует цифровую подпись в соответствии со следующей формулой:
Y = Алгоритм дешифрования (цифровая подпись, ключ дешифровки).
Алгоритм дешифрования соответствует алгоритму шифрования, который может относиться к существующему алгоритму дешифрования, такому как RSA алгоритм дешифрования и т.д.
Цифровая подпись в описанной выше формуле представляет собой цифровую подпись информации об идентификаторе H(e)NB, отправленную посредством H(e)NB на H(e)NB GW. Ключ дешифровки в данном примере представляет собой открытый ключ SeGW.
H(e)NB GW рассчитывает X′ по следующей формуле:
X′ = Алгоритм 1 (Информация об идентификаторе H(e)NB | IP адрес H(e)NB). [С]
Информация об идентификаторе H(e)NB является информацией об идентификаторе Н(е)NB, отправленной посредством H(e)NB на H(e)NB GW на этапе 307; IP адрес H(e)NB является IP адресом источника сообщения с запросом на регистрацию, отправленного посредством H(e)NB на H(e)NB GW на этапе 307.
Если Y=Х′, тогда проверка цифровой подписи прошла успешно; в противном случае проверка цифровой подписи не удалась.
H(e)NB GW получает открытый ключ из сконфигурированного сертификата SeGW, или альтернативно на этапе 307 H(e)NB отправляет сертификат SeGW на H(e)NB GW, и H(e)NB GW получает открытый ключ SeGW из полученного сертификата.
На этапе 309, если проверка цифровой подписи на этапе 308 является успешной, H(e)NB GW завершает оставшиеся процедуры регистрации H(e)NB и устанавливает контекст для него; и H(e)NB GW отправляет сообщение регистрационного ответа на H(e)NB; если проверка цифровой подписи на этапе 308 не удалась, H(e)NB GW отправляет сообщение об ошибке регистрации на H(e)NB.
На этапе 310, когда в сети нет развернутого HeNB GW, HeNB регистрируется в ММЕ. HeNB отправляет сообщение с запросом на регистрацию на ММЕ, и сообщение содержит цифровую подпись и информацию об идентификаторе HeNB.
На этапе 311 ММЕ авторизует информацию об идентификаторе и цифровую подпись HeNB способом, аналогичным способу на этапе 308.
На этапе 312, если проверка цифровой подписи на этапе 311 является успешной, ММЕ завершает оставшиеся процедуры регистрации H(e)NB и устанавливает для него контекст; и ММЕ отправляет сообщение регистрационного ответа на H(e)NB; если проверка цифровой подписи на этапе 308 не удалась, ММЕ отправляет сообщение об ошибке регистрации на H(e)NB.
Третий вариант осуществления
На фиг. 4 показана блок-схема способа защищенного доступа к H(e)NB в соответствии с третьим вариантом осуществления настоящего изобретения. Приведенным примером является способ для ММЕ или SGSN для проверки цифровой подписи информации об идентификаторе H(e)NB при регистрации UE. Как показано на фиг. 4, приведенный в примере способ защищенного доступа H(e)NB включает следующие этапы.
На этапе 401 H(e)NB включен. H(e)NB получает доступ к локальной сети и получает информацию о конфигурации IP адреса от локальной сети.
На этапе 402 H(e)NB инициирует IKEv2 согласование с SeGW. Этот процесс включает взаимную аутентификацию H(e)NB и SeGW, согласование ассоциации защиты, распределение посредством SeGW внутреннего IP адреса для H(e)NB и т.д.
На этапе 403 SeGW получает информацию об идентификаторе H(e)NB, используемого для передачи данных по базовой сети, и эта информация содержит H(e)NB ID и/или CSG ID и т.д. SeGW подписывает цифровую подпись для информации об идентификаторе H(e)NB. Когда цифровая подпись подписана с помощью частного ключа SeGW, алгоритм цифровой подписи относится к алгоритму, показанному на этапе 303. Когда цифровая подпись подписана с помощью динамического ключа сеанса, при этом может выполняться следующий алгоритм:
а), X рассчитывается по формуле [А] на этапе 303;
b), цифровая подпись = алгоритм цифровой подписи (X, динамический ключ сеанса).
При этом динамический ключ сеанса генерируется динамически посредством SeGW, например, строкой случайных чисел, или генерируется выполнением других способов.
Настоящее изобретение не предусматривает конкретный алгоритм цифровой подписи, алгоритм цифровой подписи может относиться к существующему алгоритму цифровой подписи; например, алгоритмом цифровой подписи может быть алгоритм HASH с ключом.
На этапе 404а SeGW отправляет цифровую подпись на H(e)NB; альтернативно SeGW может отправлять информацию об идентификаторе H(e)NB вместе на H(e)NB. Если информация об идентификаторе H(e)NB (например, CSG ID, H(e)NB ID) не отправлена на H(e)NB через SeGW, H(e)NB может получить ее от H(e)MS или фиксированно конфигурирует ее на H(e)NB. Если для H(e)NB необходимо назначить IP адрес, SeGW также отправляет распределенный IP адрес на H(e)NB. Информация об идентификаторе H(e)NB и ее цифровая подпись могут быть отправлены путем расширения протокола IKEv2, например, может быть расширена полезная нагрузка конфигурации (CP) IKEv2, для вложения цифровой подписи и информации об идентификаторе H(e)NB в полезную нагрузку конфигурации для отправки на H(e)NB.
На этапе 404b SeGW сохраняет динамический ключ сеанса, используемый для расчета цифровой подписи H(e)NB, в HSS/AAA.
На этапе 405 согласование IKEv2 завершается. Защищенный IPSec-туннель устанавливается между H(e)NB и SeGW.
На этапе 406 H(e)NB получает параметр конфигурации от H(e)MS.
На этапе 407, когда сеть развертывает H(e)NB GW, H(e)NB отправляет сообщение с запросом на регистрацию на H(e)NB GW, и H(e)NB отправляет информацию об идентификаторе H(e)NB и его цифровую подпись на H(e)NB GW в этом сообщении. H(e)NB GW сохраняет цифровую подпись и информацию об идентификаторе H(e)NB и IP адрес H(e)NB. H(e)NB GW завершает процесс регистрации H(e)NB и отправляет регистрационный ответ на H(e)NB.
На этапе 408, когда в сети нет развернутого HeNB GW, HeNB регистрируется в ММЕ. HeNB отправляет сообщение с запросом на регистрацию на ММЕ, и сообщение содержит информацию об идентификаторе HeNB и его цифровую подпись. ММЕ сохраняет информацию об идентификаторе H(e)NB, цифровую подпись и IP адрес HeNB. ММЕ завершает процесс регистрации H(e)NB и отправляет регистрационный ответ на H(e)NB.
Четвертый вариант осуществления
На фиг. 5 показана блок-схема способа защищенного доступа к H(e)NB в соответствии с четвертым вариантом осуществления настоящего изобретения. Приведенным примером является способ для ММЕ или SGSN для проверки цифровой подписи информации об идентификаторе H(e)NB при регистрации UE. Данный вариант осуществления представляет блок-схему UE, выполняющего подключение, маршрутизацию или обновление отслеживаемой области через H(e)NB. Как показано на фиг. 5, приведенный в примере способ защищенного доступа H(e)NB включает следующие этапы.
На этапе 501, когда UE включено под Н(е)NB или UE перемещается в один H(e)NB, расположенный в новой области маршрутизации или отслеживаемой области, UE отправляет сообщение с запросом на подключение или сообщение с запросом на обновление области маршрутизации/отслеживаемой области на H(e)NB.
На этапе 502 H(e)NB переадресует описанное выше сообщение с запросом на регистрацию UE через S1 интерфейс. Когда H(e)NB GW развернут, сообщение отправляется на H(e)NB GW; когда H(e)NB GW не развернут, сообщение отправляется прямо на ММЕ. H(e)NB GW принимает решение, соответствует ли IP адрес H(e)NB IP адресу H(e)NB, хранимому в этом контексте. Если соответствует, H(e)NB GW возвращает сообщение об ошибке на H(e)NB.
На этапе 503, когда H(e)NB GW развернут, H(e)NB GW переадресует сообщение на этапе 502 и получает информацию об идентификаторе H(e)NB, факультативно IP адрес H(e)NB и/или цифровую подпись, из контекста; и отправляет эти сообщения вместе с S1 сообщением, отправленным на H(e)NB GW посредством H(e)NB на этапе 502 на SGSN (для GERAN или UTRAN) или ММЕ (для EUTRAN). H(e)NB GW сохранил описанную выше информацию на этапе 407.
На этапе 504 MME/SGSN получает ключ сеанса цифровой подписи от HSS/AAA в соответствии с информацией об идентификаторе H(e)NB, полученной на этапе 503 (например, H(e)NB ID), и получает другую информацию H(e)NB от HSS/AAA, например, список CSG ID, поддерживаемый посредством Н(е) NB; факультативно HSS/AAA отправляет ключ цифровой подписи на MME/SGSN.
На этапе 505, если H(e)NB GW отправляет цифровую подпись на MME/SGSN на этапе 503, MME/SGSN проверяет цифровую подпись H(e)NB.
Когда цифровая подпись подписана для информации об идентификаторе H(e)NB с помощью открытого и частного ключа, алгоритм проверки переходит на этап 308. При этом информация об идентификаторе H(e)NB, IP адрес H(e)NB и цифровая подпись отправляются на MME/SGSN посредством H(e)NB GW на этапе 503.
Когда цифровая подпись подписана для информации об идентификаторе H(e)NB с помощью ключа сеанса, алгоритм проверки является следующим:
а). X′ рассчитывается по формуле [С] на этапе 308;
b). Y = алгоритм цифровой подписи (X′, ключ сеанса).
Если Y аналогичен для цифровой подписи, полученной на этапе 502, тогда это указывает на то, что проверка прошла успешно; в противном случае проверка не удалась.
На этапе 506 SGSN/MME инициируется для завершения последующей процедуры подключения UE или обновления области маршрутизации/отслеживаемой области, включая управление, например, SGSN/MME принимает решение, разрешить ли UE доступ к H(e)NB в соответствии со списком CSG, поддерживаемым посредством H(e)NB, и со списком CSG, на который подписано UE, и т.д.
Если проверка цифровой подписи на этапе 505 будет неуспешной, процедура подключения UE или процедура обновления области маршрутизации/отслеживаемой области потерпит неудачу, и процесс завершается.
На фиг. 6 показана структурная схема системы защищенного доступа к исходному (развитому) узлу В (H(e)NB) в соответствии с вариантом осуществления настоящего изобретения. В данном примере приведена другая система защищенного доступа к H(e)NB для осуществления проверки идентификатора H(e)NB. В частности, интерфейс связи добавлен между SeGW и ММЕ или SGSN и H(e)NB GW. После того как ММЕ или H(e)NB GW получит информацию об идентификаторе, отправленную посредством H(e)NB, MME/SGSN/H(e)NB GW отправляет сообщение с запросом на проверку идентификатора на SeGW по этому только что добавленному интерфейсу, таким образом SeGW проверяет истинность идентификатора H(e)NB. Как показано на фиг. 6, Sx и Sy представляют собой только что добавленные интерфейсы. Интерфейс Sx находится между ММЕ и SeGW, используемым для ММЕ для проверки идентификатора H(e)NB, и этот интерфейс используется только в сцене, которую H(e)NB GW не разворачивает. Интерфейс Sy расположен между H(e)NB GW и SeGW, используемым для H(e)NB GW для проверки идентификатора H(e)NB. Данная схема дополнительно подробно описана ниже в сочетании с блок-схемой.
Пятый вариант осуществления
На фиг. 7 показана блок-схема способа защищенного доступа к H(e)NB в соответствии с четвертым вариантом осуществления настоящего изобретения. Данный пример описывает блок-схему включения и регистрации H(e)NB. Как показано на фиг. 7, приведенный в примере способ защищенного доступа H(e)NB включает следующие этапы.
На этапе 701 H(e)NB включен. H(e)NB получает доступ к локальной сети и получает информацию о конфигурации IP адреса от локальной сети.
На этапе 702 H(e)NB инициирует IKEv2 согласование с SeGW. Этот процесс включает взаимную аутентификацию H(e)NB и SeGW, согласование ассоциации защиты, распределение посредством SeGW внутреннего IP адреса для H(e)NB и т.д.
На этапе 703 H(e)NB получает параметр конфигурации от H(e)MS.
На этапе 704 сеть развертывает H(e)NB GW, H(e)NB отправляет сообщение с запросом на регистрацию на H(e)NB GW, и H(e)NB отправляет информацию об идентификаторе H(e)NB на H(e)NB GW в этом сообщении.
На этапе 705 для проверки идентификатора H(e)NB H(e)NB GW отправляет сообщение с запросом идентификатора H(e)NB на SeGW, и сообщение содержит IP адрес H(e)NB (то есть, IP адрес, назначенный для H(e)NB посредством SeGW).
На этапе 706 SeGW запрашивает информацию об идентификаторе H(e)NB в соответствии с IP адресом H(e)NB и возвращает информацию об идентификаторе обратно на H(e)NB GW.
На этапе 707 H(e)NB GW сохраняет информацию об идентификаторе H(e)NB, завершает оставшиеся процедуры регистрации H(e)NB и устанавливает контекст для него; H(e)NB GW отправляет сообщение регистрационного ответа на H(e)NB.
На этапе 708, когда сеть не развертывает H(e)NB GW, H(e)NB отправляет сообщение с запросом на регистрацию на ММЕ, и H(e)NB отправляет информацию об идентификаторе H(e)NB на ММЕ в этом сообщении.
На этапе 709 для проверки идентификатора H(e)NB ММЕ отправляет сообщение с запросом идентификатора H(e)NB на SeGW, и сообщение содержит IP адрес H(e)NB (то есть IP адрес, назначенный для H(e)NB посредством SeGW).
На этапе 710 SeGW запрашивает информацию об идентификаторе H(e)NB в соответствии с IP адресом H(e)NB и возвращает информацию об идентификаторе обратно на ММЕ.
На этапе 711 ММЕ сохраняет информацию об идентификаторе H(e)NB, завершает оставшиеся процедуры регистрации H(e)NB и устанавливает контекст для него; ММЕ отправляет сообщение регистрационного ответа на H(e)NB.
Варианты осуществления настоящего изобретения дополнительно предоставляют систему защищенного доступа к H(e)NB, содержащую SeGW, H(e)NB и элемент базовой сети; при этом:
SeGW сконфигурирован для подписания цифровой подписи для информации об идентификаторе H(e)NB и отправки цифровой подписи на H(e)NB;
H(e)NB сконфигурирован для отправки информации об идентификаторе H(e)NB и цифровой подписи на элемент базовой сети при регистрации H(e)NB, или при подключении UE, или при обновлении отслеживаемой области, или при обновлении маршрутизации при получении доступа через H(e)NB;
элемент базовой сети сконфигурирован для выполнения проверки правильности цифровой подписи и информации об идентификаторе H(e)NB.
При этом SeGW может использовать частный ключ SeGW для подписи информации об идентификаторе H(e)NB;
соответственно, элемент базовой сети может выполнять проверку правильности цифровой подписи и информации об идентификаторе H(e)NB посредством открытого ключа SeGW.
При этом SeGW может использовать динамический ключ сеанса для подписания информации об идентификаторе H(e)NB; и
SeGW может уведомлять сервер домашних абонентов (HSS)/сервер аутентификации, авторизации и учета (AAA) динамического ключа сеанса, и HSS/AAA сервер сохраняет динамический ключ сеанса.
При этом элемент базовой сети может получать от AAA/HSS динамический ключ сеанса для цифровой подписи информации об идентификаторе H(e)NB, и проверять информацию об идентификаторе H(e)NB с помощью динамического ключа сеанса.
При этом информация об идентификаторе H(e)NB может быть H(e)NB ID и внутренним IP адресом H(e)NB, или представляет собой ID закрытой группы абонентов (CSG) и внутренний IP адрес H(e)NB, или представляет собой H(e)NB ID, CSG ID и внутренний IP адрес H(e)NB; и
элемент базовой сети может быть узлом управления мобильностью (ММЕ), обслуживающим узлом поддержки GPRS (SGSN) или H(e)NB GW.
Элемент базовой сети согласно варианту осуществления настоящего изобретения сконфигурирован для получения информации об идентификаторе, отправленной посредством исходного (развитого) узла В (H(e)NB) и цифровой подписи информации об идентификаторе посредством шлюза безопасности (SeGW) и выполнения проверки правильности информации об идентификаторе и цифровой подписи.
Другой элемент базовой сети согласно варианту осуществления настоящего изобретения сконфигурирован для: получения информации об идентификаторе исходного (развитого) узла В (H(e)NB), выполняющего аутентификацию идентификатора через интерфейс связи между элементом базовой сети и шлюзом безопасности (SeGW), выполнения проверки правильности информации об идентификаторе, сообщаемой посредством H(e)NB, и приема регистрации H(e)NB после прохождения проверки.
Специалистам в данной области техники должно быть понятно, что система защиты H(e)NB и элемент базовой сети в представленном примере будут понятны со ссылкой на описание в раскрытых выше вариантах осуществления один - четыре.
Специалистам ясно, что все или некоторые стадии вышеуказанного способа могут выполняться программами, выдающими команды соответствующим аппаратным средствам, и что эти программы могут храниться в считываемой компьютером запоминающей среде, такой, как постоянное запоминающее устройство, магнитный диск или оптический диск и т.д. Альтернативно, все или некоторые стадии в вышеописанных примерах могут осуществляться с использованием одной или нескольких интегральных схем. Соответственно каждый модуль/блок в вышеописанных вариантах осуществления может быть реализован с использованием определенного вида аппаратных средств или может быть реализован с использованием определенного вида модуля программного обеспечения. Настоящее изобретение не устанавливает ограничений относительно каких-либо форм сочетаний аппаратного и программного обеспечения.
Приведенное выше описание является только предпочтительными вариантами осуществления настоящего изобретения и не предназначено для ограничения настоящего изобретения. Специалистам в данной области техники будет очевидно, что в настоящее изобретение могут быть внесены разнообразные изменения. Любые изменения и/или эквивалентные варианты, выполненные без отступления от сущности настоящего изобретения, включены в формулу изобретения, которая дополняет данное описание.
Промышленная применимость
Решение согласно вариантам осуществления настоящего изобретения позволяет устранить регистрацию недопустимого H(e)NB непосредственно в элементе базовой сети и реализует доступ к услугам UE, тем самым сохраняя защищенность сети.