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

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

Иллюстрации

Показать все

Реферат

Область техники, к которой относятся изобретения

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

Уровень техники

Обеспечение протокола сети Интернета по радио (IOTA), протокола применения беспроводной связи (ППБС) (WAP) и спецификации PUSH («проталкивание») представляют собой протоколы беспроводной связи, которые дают возможность сетевым операторам программировать и «проталкивать» информационное наполнение в ручные телефоны для сотовой связи по радио, используя допускаемый ППБС браузер. Протокол обеспечения IOTA был воплощен операторами радиосвязи МДКР (множественного доступа с кодовым разделением), а протокол обеспечения ППБС был воплощен операторами сети связи ГСМС (глобальной системы мобильной связи).

Чтобы инициировать сеанс связи обеспечения ППБС, посреднический шлюз «проталкивания» (ПШП) посылает сообщение межсетевого протокола (МП), известное как запрос инициирования сеанса связи (ЗИСС), или приветственный запрос, на подвижную станцию. Сеанс связи обеспечения IOTA инициируется аналогичным образом посредством посылки запроса сеанса связи в форме модифицированного сообщения службы коротких сообщений (SMS), известного как запрос самонастройки, из центра SMS (SMSС) на подвижную станцию.

В сеансах связи обеспечения IOTA, SMS или запрос самонастройки содержит информацию, обеспечивающую возможность телефонному браузеру выбирать документы команды управления подвижными объектами (КУПО) из точно установленного адреса. Документы КУПО управляют особыми параметрами в мобильном ручном телефоне, например, отдавая приказы ручному телефону считывать и записывать параметры телефона, инициировать замену А-клавиши (клавиши доступа) и обновлять привилегированный перечень роуминга (PRL) и т.д.

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

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

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

Краткое описание чертежей

Фиг.1 представляет систему связи согласно примерному применению изобретения.

Фиг.2 представляет блок-схему процесса для примерного применения изобретения.

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

Фиг.4 представляет примерное обеспечение устройства беспроводной связи сообщения запроса сеанса связи.

Осуществление изобретения

Фиг.1 иллюстрирует систему 100 связи, содержащую в общем беспроводную сеть 110 связи, например сотовую сеть МДКР или ГСМС/ОУПР (общие услуги пакетной радиосвязи), или некоторую другую инфраструктуру беспроводной сети связи, для обеспечения услуг связи для устройств беспроводной связи.

Устройством беспроводной связи может быть мобильный беспроводной ручной телефон 120, например, МДКР, или ГСМС/ОУПР, или некоторое другое мобильное устройство связи. На фиг.2 представлено примерное устройство 200 беспроводной связи, содержащее в общем процессор 210, подсоединенный к запоминающему устройству 220, например ОЗУ (оперативному запоминающему устройству) и ПЗУ (постоянному запоминающему устройству), и в некоторых вариантах осуществления к SIM-карте (модулю идентификации абонентов), USIM, R-UIM, NVM и т.д. Процессор также подсоединен к приемопередатчику 230 радиосвязи и к устройству 240 отображения. Кроме того, процессор подсоединен ко входу 250, например к портам микрофона и данных, и к выходам 260, например к портам громкоговорителя и данных.

На фиг.1 сеть 110 беспроводной связи подсоединена к шлюзу 130, который соединен с сервером 140. В применениях обеспечения Интернета по радио (IOTA), требуемых теперь многими операторами беспроводной связи МДКР, обеспечивающими обслуживание передачи речи и данных, сервер 140 представляет собой сервер обеспечения IOTA, а шлюз 130 представляет шлюз обеспечения, например шлюз обеспечения протокола применения беспроводной связи (ППБС). В примерном варианте осуществления беспроводная сеть 110 включает в себя центр обслуживания службы коротких сообщений (SMSC). В ППБС и других применениях обеспечения сервер и шлюз могут быть идентифицированы по-другому, но эти и другие примерные обозначения не предназначены для ограничения изобретения.

Запрос сеанса связи устройства беспроводной связи инициируется в общем из сервера, хотя точкой инициирования запроса сеанса связи может быть некоторый другой источник, поддерживающий связь с сервером. В частности, в блок-схеме 300 последовательности операций на фиг.3 в блоке 310 посреднический шлюз «проталкивания» (ПШП) посылает клиенту ЗИСС или запрос приветствия. В других вариантах осуществления, в более общем случае, запрос сеанса связи может быть инициирован из некоторого другого сервера и в формате, отличающемся от ЗИСС, например запрос самонастройки.

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

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

На фиг.1 запрос сеанса связи обычно передается от сервера 140 к шлюзу и затем к сети связи, которая сообщает или «проталкивает» запрос сеанса связи в мобильный ручной телефон. В примерном применении обеспечения IOTA, иллюстрируемом на фиг.4, сервер 410 обеспечения IOTA/PUSH создает сообщение 402 запроса самонастройки и посылает его в шлюз 420 обеспечения ППБС или «проталкивания», который направляет сообщение самонастройки в сеть 430 беспроводной связи, например в его SMSC. Сеть беспроводной связи посылает сообщение в мобильный ручной телефон 440. Передача запроса от сервера к подвижной станции идентифицируется в потоке 450 сообщений связи.

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

Перечень достоверных источников может быть получен подвижной станцией от сети и может периодически обновляться. Перечень достоверных источников хранится в памяти на подвижной станции, например в SIM-карте, USIM, R-UIM, NVM и т.д.

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

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

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

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

На фиг.4 в некоторых применениях сервер 410 запрашивает сигнатуру у сети 430 после первой посылки запроса сеанса связи без сигнатуры и после приема отказа в сеансе связи от подвижной станции 440, например, из-за отсутствия достоверности при сравнении запроса сеанса связи с перечнем достоверных точек или источников контактов. В других применениях сервер 410 запрашивает сигнатуру у сети 430 прежде или без первой посылки сообщения с запросом сеанса связи без аутентифицирующих данных сигнатуры. Таким образом, в некоторых применениях, этапы 450 и 452 на фиг.4 не нужны и могут быть опущены с помощью первого запроса сигнатуры у сети или другого источника санкционирования.

Сигнатура в общем объединяется с сообщением запроса сеанса связи, например, в его заголовке, сервером и, таким образом, передается с запросом сеанса связи. На фиг.4 после приема аутентифицирующей сигнатуры от сети 430 или другого источника, в ответ на запрос 454 сигнатуры сигнатура объединяется с сообщением запроса сеанса связи, например, путем размещения ее в заголовке сообщения или иначе, объединяя сигнатуру и сообщение, причем эти подробности не предназначены для ограничения изобретения. Этап объединения может быть выполнен в сервере или в некотором другом местоположении. На фиг.3 в блоке 340 к сообщению добавляется сигнатура, которую также можно рассматривать, как ключ защиты.

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

В примерном варианте осуществления фиг.5 заголовок сообщения включает в себя поле 512 данных сигнатуры для сохранения данных санкционирующей сигнатуры, принятых от сети. Как было отмечено, в одном варианте осуществления сообщение запроса сеанса связи представляет собой запрос инициирования сеанса связи протокола применения беспроводной связи, а в другом варианте осуществления он представляет собой запрос самонастройки Интернета по радио (IOTA).

На фиг.4 сигнатура также должна быть обеспечена для подвижной станции 440 сетью 430, чтобы подвижная станция могла проверить допустимость сигнатуры, принятой от сервера 410. На фиг.4 сигнатура сообщается подвижной станции 440 от сети 430 в ряде связанных передач между ними, которые идентифицированы группой передаваемых потоков сообщений 460.

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

На фиг.4 в некоторых применениях сигнатура передается на подвижную станцию 440 только после того, как сервер 410 делает запрос 454 сигнатуры. В более общем случае, однако, сигнатура может сообщаться подвижной станции 440 в любое время до запроса 454 сигнатуры, выполняемого сервером, как на фиг.4 обозначено стрелкой 461.

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

На фиг.4 после приема сигнатуры от сети или другого источника санкционирования и объединения ее с запросом сеанса связи сервер 410 передает, или ретранслирует, запрос сеанса связи и сигнатуру на подвижную станцию 440, как обозначено в потоке сообщений 458 связи.

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

На фиг.4 при процессе 464, если сигнатура достоверная, запрос сеанса связи обрабатывается в подвижной станции 440, например подвижная станция может впоследствии выбирать документ КУПО или «проталкивать» информационное наполнение. В некоторых применениях после проверки допустимости сигнатуры подвижная станция сначала сообщает о принятии серверу 410, при сообщении 466 о принятии, перед обработкой запроса сеанса связи.

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

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

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

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

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

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

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

4. Способ по п.3, по которому генерируют контрольную сигнатуру до приема и отклонения запроса сеанса связи.

5. Способ по п.3, по которому генерируют контрольную сигнатуру после отклонения запроса сеанса связи.

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

7. Способ по п.1, по которому отклоняют запрос сеанса связи, если инициатор запроса сеанса связи отсутствует в перечне достоверных контактов.

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

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

10. Способ по п.1, по которому обновляют перечень достоверных контактов относительно инициатора запроса сеанса связи по сигнатуре, если сигнатура сеанса связи по сигнатуре достоверная.

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

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

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

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