BRPI0517521B1 - Método e sistema para autenticar um assinante de uma primeira rede para acessar um serviço de aplicação através de uma segunda rede - Google Patents

Método e sistema para autenticar um assinante de uma primeira rede para acessar um serviço de aplicação através de uma segunda rede Download PDF

Info

Publication number
BRPI0517521B1
BRPI0517521B1 BRPI0517521-6A BRPI0517521A BRPI0517521B1 BR PI0517521 B1 BRPI0517521 B1 BR PI0517521B1 BR PI0517521 A BRPI0517521 A BR PI0517521A BR PI0517521 B1 BRPI0517521 B1 BR PI0517521B1
Authority
BR
Brazil
Prior art keywords
network
subscriber
fact
access
address
Prior art date
Application number
BRPI0517521-6A
Other languages
English (en)
Inventor
Gaetano Di Caprio
Corrado Moiso
Paolo De Lutiis
Original Assignee
Telecom Italia S.P.A.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=34959133&utm_source=***_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=BRPI0517521(B1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Telecom Italia S.P.A. filed Critical Telecom Italia S.P.A.
Publication of BRPI0517521A publication Critical patent/BRPI0517521A/pt
Publication of BRPI0517521B1 publication Critical patent/BRPI0517521B1/pt

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5084—Providing for device mobility
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/72—Subscriber identity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/16—Gateway arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

métodos para autenticar um assinante de uma primeira rede e de diversas primeiras redes para acessar um serviço de aplicação, e, sistema para autenticar um assinante de uma primeira rede para acessar serviços de aplicação. a presente invenção relaciona-se a um sistema e método para autenticar um assinante de uma primeira rede, por exemplo, uma rede gprs/gsm, para acessar serviços de aplicação através de uma segunda rede, onde a segunda rede é uma rede de dados por pacotes (pdn), por exemplo, a intemet. o sistema de acordo com as realizações preferidas da invenção inclui uma estação móvel ms (2) conectada a uma rede celular e apta a gerar mensagens de requisição de acesso incluídas nos pacotes de dados, citadas mensagens de requisição de acesso sendo expressas com uma sintaxe que é conforme a um protocolo de nível de aplicação; um servidor de alocação aaa (7) apto a alocar um endereço na citada segunda rede, ao citado assinante (endereço de assinante) e a prover um mapeamento entre o endereço de assinante e um primeiro identificador de assinante; um ponto de conexão (6), por exemplo, uma ggsn, que interfaceia a primeira rede com a segunda rede e designa o endereço de assinante ao ms 2; um injetor de ficha de serviço sti (10) conectado ao ponto de conexão (6) e apto a interceptar os pacotes de dados gerados a partir da estação de ponto de extremidade e direcionados à segunda rede através do ponto de conexão (6) e capturar nos pacotes de dados pelo menos o endereço de assinante, e uma entidade lógica ia de autoridade de identidade (9) conectada ao sti 10 e apta a executar as seguintes funções: receber o endereço de assinante e a mensagem de requisição de acesso da primeira entidade lógica, reconhecer o protocolo de nível de aplicação da mensagem de requisição de acesso, requisitar o primeiro identificador de assinante ao servidor de alocação, gerar uma ficha de autenticação de acordo com o protocolo de nível de aplicação, a citada ficha incluindo um segundo identificador de assinante, e associar a ficha de autenticação à mensagem de requisição de acesso.

Description

“MÉTODO E SISTEMA PARA AUTENTICAR UM ASSINANTE DE UMA PRIMEIRA REDE PARA ACESSAR UM SERVIÇO DE APLICAÇÃO ATRAVÉS DE UMA SEGUNDA REDE”
Campo da invenção [0001] A presente invenção relaciona-se a um método e um sistema de autenticação para identificar um assinante de uma primeira rede, para uma rede de dados por pacotes, por exemplo, a Internet. Em particular, a invenção foi desenvolvida para seu uso em autenticação de assinantes de uma rede móvel para uma rede de dados por pacotes, utilizando uma identificação de assinante associada ao assinante na rede móvel.
Fundamentos [0002] O número de usuários que acessam Redes de Dados por Pacotes (PDN) privadas ou públicas, por exemplo, Internet, a partir de localizações remotas está crescendo enormemente. Em adição, a visão de serviços multimídia que estão disponíveis para pessoas, independente de sua localização, tem conduzido o desenvolvimento de redes celulares usando uma conexão comutada por pacotes, por exemplo, usando o Protocolo Internet (IP) significando que uma conexão virtual está sempre disponível para qualquer outro ponto de extremidade na rede. Padrões de serviços de comunicação sem fio baseados em pacotes incluem Serviço de Rádio por pacote Geral (GPRS), EDGE (Taxas de Dados Reforçadas para Evolução Global) e UMTS (Sistema Universal de Telecomunicações Móveis).
[0003] Recentemente, devido à redução de custos e às capacidades de conexão sempre crescentes, mais e mais sistemas de comunicação de dados de alta velocidade estão sendo instalados em premissas de usuário. Estes sistemas de comunicação de dados trabalham, por exemplo, nas mesmas linhas de cobre de par trançado da Rede Telefônica Comutada Pública (PSTN) para conexão à Internet. As conexões à Internet através de linhas telefônicas comuns geralmente têm lugar através da tecnologia de acesso de
Petição 870180053298, de 20/06/2018, pág. 12/66 / 48
Linha de Assinante Digital (DSL) embora outros modems de alta velocidade sejam também usados. DSL usa um modem especializado para habilitar a transferência de dados de alta velocidade entre a residência do assinante e a central telefônica mais próxima, através da fiação de cobre padrão usada para trazer serviço telefônico doméstico. Há um número de esquemas de comunicação DSL (geralmente referidos como tecnologias xDSL) mas uma das formas mais comuns disponível comercialmente é ADSL (DSL Assimétrica), na qual as taxas de dados a jusante (isto é, para o assinante) são várias vezes mais rápidas que as taxas de dados a montante (isto é, a partir do assinante).
[0004] Uma outra tecnologia de acesso que ganhou interesse nos anos recentes é a fibra doméstica (FTTH), um sistema de acesso de faixa larga de alta velocidade no qual uma fibra óptica corre da comutação telefônica para as premissas de usuário.
[0005] Nas conexões Internet sem fio de alcance curto, um computador ou conjunto portátil (por exemplo, PDA) com capacidade sem fio incorporada, usa tecnologias de rádio para enviar e receber dados a qualquer lugar dentro do alcance de um ponto de acesso ou ponto de conexão, que atua como uma estação base de radiodifusão e recepção e como interface entre a rede sem fio e uma rede com fio. Por exemplo, tecnologias rádio entre o dispositivo sem fio e o ponto de acesso podem ser baseadas no padrão IEEE 802.11 (especificação Wi-Fi®) ou no padrão IEEE 802.16 (especificação WiMAX).
[0006] Tecnologias de acesso de faixa larga tem permitido que os provedores de serviço expandam seu conteúdo e ofertas de serviço a ambos usuários comerciais e domésticos. Por exemplo, um usuário pode subscrever serviços ou aplicações múltiplos, tais como serviço de voz, serviço de acesso Internet, serviço de vídeo, serviço de jogos, etc., a partir de um ou mais provedores de serviço. Estes serviços e/ou aplicações disponíveis através de
Petição 870180053298, de 20/06/2018, pág. 13/66 / 48 uma PDN privada ou pública (por exemplo, Internet) podem ser fornecidos através de uma conexão de rede única, tal como uma linha DSL.
[0007] Por outro lado, um número constantemente crescente de serviços disponíveis nas PDN concedem acesso somente a usuários autorizados, tal como no caso de serviços pagos por seção, serviços que requerem assinatura ou serviços sob medida, de acordo com o perfil de seus usuários. Alguns procedimentos de autenticação convencionais usam senhas, por exemplo, cadeias de caracteres reconhecidos por meios automáticos que permitem que um usuário acesse arquivos protegidos, ou dispositivos de entrada/saída.
[0008] O requerente fez as seguintes considerações. Primeiramente, sistemas de autenticação baseados em senha são naturalmente não transparentes para o usuário, que tem que entrar com sua senha ao entrar no serviço. Isto pode se tornar particularmente indesejável quando um usuário deseja acessar diversos serviços durante uma sessão. Em segundo lugar, embora sento tecnologicamente simples de implementar, senhas são fáceis de comprometer pois são vulneráveis à duplicação ou roubo.
[0009] Sistemas de comunicação móveis controlam recursos de uma rede, que são utilizados por estações móveis correspondendo a usuários autorizados. Em um Sistema Global para comunicações Móveis (GSM), a estação móvel (MS) inclui um Módulo de Identidade de Assinante (SIM) que contém informação de assinante incluindo dados usados para permitir que o MS obtenha acesso à infra-estrutura de rede do sistema GSM. Os SIM podem ser vistos como dispositivos de segurança, uma vez que provêm um meio único para identificar assinantes individuais; estes usam criptografia e capacidade computacional intrínseca para armazenar informação secreta que jamais é divulgada externamente de uma forma clara.
[00010] Em um sistema de rede GSM convencional, várias bases de dados estão disponíveis para controle de chamada e para fins de autenticação e segurança, que são tipicamente: o registro de localização doméstico (HLR),
Petição 870180053298, de 20/06/2018, pág. 14/66 / 48 o registro de localização de visitante (VLR), o centro de autenticação (AUC) e o registro de identidade de equipamento (EIR). Para todos os usuários registrados com um operador de rede, dados permanentes (tais como o perfil do usuário) bem como dados temporários (tais como a localização corrente do usuário) são armazenados no HLR. No caso de uma chamada para um usuário, o HLR é sempre questionado primeiramente, para determinar a localização corrente do usuário. Um VLR é responsável por um grupo de áreas de localização e armazena os dados daqueles usuários que estão correntemente nesta área de responsabilidade. Isto inclui partes de dados de usuário permanentes que tenham sido transmitidos do HLR para o VLR para acesso mais rápido. Porém, o VLR pode também designar e armazenar dados locais tais como uma identificação temporária. O AUC gera e armazena dados relacionados a segurança, tais como códigos usados para autenticação e criptografia, ao passo que o EIR registra dados de equipamento ao invés de dados de assinante.
[00011] GSM distingue explicitamente entre usuário e equipamento e trata com eles separadamente. Vários identificadores de assinante e equipamento têm sido definidos; eles são necessários para o gerenciamento de mobilidade de assinante e para equacionamento de todos os elementos de rede restantes. A identidade de equipamento de estação móvel internacional (IMEI) que é uma espécie de número serial, identifica univocamente uma estação móvel (MS) internacionalmente. A IMEI é alocada pelo fabricante do equipamento e registrada pelo operador de rede que a armazena no EIR. Cada usuário registrado, isto é, o assinante, é univocamente identificado por sua identidade de assinante móvel internacional (IMSI). A IMSI é tipicamente armazenada no SIM. Uma MS pode somente ser operada se um SIM com uma IMSI válida for inserido no equipamento com uma IMEI válida. O “número de telefone real” de uma estação móvel é o número ISDN de assinante móvel (MSISDN). Este é designado ao assinante (isto é, seu SIM) de tal modo que
Petição 870180053298, de 20/06/2018, pág. 15/66 / 48 uma configuração de estação móvel pode ter vários MSISDN dependendo do SIM.
[00012] Serviço de Rádio por pacote Geral (GPRS) é um serviço projetado para redes celulares digitais (por exemplo, GSM ou Serviço de Comunicação Pessoal - PCS) e originalmente desenvolvido para GSM. O GPRS melhora e simplifica grandemente o acesso sem fio a redes de dados por pacotes, por exemplo, a Internet. Este aplica um princípio de rádio por pacote para transferir pacotes de dados de usuário de um modo eficiente, entre estações móveis e redes de dados por pacotes externas. Os pacotes podem ser roteados diretamente a partir de/para estações móveis GPRS para/a partir de outros terminais GPRS ou para/a partir de PDN. As redes com base no Protocolo Internet (IP) (por exemplo, a Internet global ou Intranets privadas/corporativas) e redes X.25 são suportadas na versão corrente do GPRS.
[00013] O GPRS otimiza o uso de recursos de rede e recursos rádio e não comanda mudanças para um Centro de Comutação Móvel (MSC) base da intra-estrutura GSM. No sentido de se integrar na arquitetura GSM existente, a arquitetura GPRS geralmente compreende um Nó de Suporte GPRS de Ponto de Conexão (GGSN) e um Nó de Suporte GPRS de Serviço (SGSN). O GGSN, que está no mesmo nível hierárquico que o MSC, atua como ponto de conexão para outras redes de dados por pacotes tal como a Internet. O SGSN é o nó de serviço que habilita conexões virtuais para o dispositivo móvel habilitado pelo GPRS e fornecimento de dados. O SGSN envia dados para e recebe dados das estações móveis, e mantém informação sobre a localização de uma estação móvel (MS). O SGSN se comunica entre o MS e o GGSN.
[00014] A funcionalidade de segurança GPRS é tipicamente equivalente à segurança GSM existente. O SGSN efetua autenticação e procedimentos de configuração de cifragem com base nos mesmos algoritmos, códigos e critérios no GSM existente. GPRS usa um algoritmo de cifragem otimizado
Petição 870180053298, de 20/06/2018, pág. 16/66 / 48 para transmissão de dados por pacotes.
[00015] Para trocar pacotes de dados com PDN externas após uma anexação GPRS bem sucedida, uma MS precisa requerer um ou mais endereços usados na PDN, por exemplo, um endereço IP, no caso da PDN, é uma rede IP. Este endereço é chamado endereço PDP (endereço de Protocolo de Dados de Pacote). Para cada sessão, um assim chamado contexto PDP é criado, o qual descreve as características da sessão. Este contém o tipo PDP (por exemplo, IPv4), o endereço PDP designado à estação móvel (por exemplo, 164.130.10.10), a Qualidade de Serviço requisitada (QoS) e o endereço de um GGSN que serve como ponto de acesso à PDN. Este contexto é armazenado na MS, SGSN e GGSN. Com um contexto PDP ativo, a estação móvel é “visível” para a PDN externa e é capaz de enviar e receber pacotes de dados. O mapeamento entre os dois endereços, PDP e IMSI habilita o GGSN a transferir pacotes de dados entre a PDN e a MS. Um usuário pode ter vários contextos PDP simultâneos ativos ao mesmo tempo.
[00016] O pedido de patente WO No. 01/67716 descreve um método para associar um número MSISDN de um terminal móvel a um endereço IP designado temporariamente para uso nos processos de autenticação, cobrança e personalização em uma rede de protocolo de aplicação sem fio (WAP).
[00017] O pedido de patente WO No. 01/03402 descreve um método de autenticação para identificar um assinante de uma primeira rede (isto é, a rede GPRS) em uma segunda rede (por exemplo, uma rede IP) onde um endereço da segunda rede é alocado ao assinante. Informação sobre um mapeamento entre o endereço da segunda rede, por exemplo, o endereço IP, e uma identidade de assinante, é gerada e transmitida à segunda rede. A identidade do assinante pode ser a IMSI e/ou MSISDN do assinante.
[00018] O requerente notou que autenticar o acesso a uma rede IP associando uma identidade de assinante ao endereço IP é geralmente vulnerável a spoofing de pacotes IP, o que permite que um intruso na Internet
Petição 870180053298, de 20/06/2018, pág. 17/66 / 48 efetivamente personifique um endereço IP de sistema local. Em adição, as duas redes deveriam ser diretamente conectadas (fazendo uso de endereços IP privados roteados possíveis) ou necessitam de um plano de endereço compatível.
[00019] O pedido de patente WO No. 01/17310 descreve um sistema para autenticar um usuário requerendo acesso a uma PDN, aplicando princípios de segurança GSM. Um computador principal remoto está conectado à PDN, através de uma rede de acesso e uma MS é acoplada a uma rede móvel conectada à PDN. Em resposta a receber uma requisição de usuário para a PDN, a PDN gera e envia uma ficha de autenticação ao usuário, via rede de acesso e computador principal remoto, o usuário envia a ficha de autenticação de volta à PDN, através da rede móvel, onde a PDN compara as fichas de autenticação para determinar quanto a autorizar o acesso de usuário à PDN.
[00020] O requerente observou que o sistema de autenticação descrito não é transparente ao usuário, que tem que aguardar a autenticação e tem que enviar a ficha de autenticação recebida de volta à PDN. Ainda mais, uma vez que o servidor remoto precisa conhecer o número telefônico do usuário, o sistema descrito pode comprometer a privacidade do usuário.
[00021] O pedido de patente US No. 2004/0132429 descreve um método e sistema para prover acesso a uma conta de e-mail via uma rede de comunicação móvel, sem conhecimento especial da programação do terminal móvel ou quaisquer parâmetros POP3 ou SMTP. O terminal móvel é pré configurado com um endereço de servidor POP3/SMTP padrão. Para acessar uma conta de e-mail é feita comunicação entre o cliente do terminal móvel e um servidor de proxy via rede móvel, usando POP3/SMTP padrão. O usuário pode ter acesso autorizado a uma conta de e-mail baseado somente em seu MSISDN.
[00022] O UMTS (Sistema Universal de Telecomunicações Móveis) pode ser visto como a evolução direta das redes GSM/GPRS. As funções de
Petição 870180053298, de 20/06/2018, pág. 18/66 / 48 segurança do UMTS são baseadas no que foi implantado no GSM, tal como a autenticação de assinante, ao passo que algumas das funções de segurança foram adicionadas e algumas existentes foram melhoradas.
[00023] A comutação de pacotes utiliza pacotes de dados que são comparativamente blocos curtos de dados de mensagem. Os pacotes podem ser de extensão fixa como no modo de transferência síncrono (ATM) ou podem ser de extensão variável como em um “frame relay” ou protocolo Internet (IP). Um cenário desejável é que as infra-estruturas de rede sem fio comutada por pacotes suportem telefonia Internet. Telefonia Internet, ou telefonia IP, refere-se a uma classe de aplicações que mesclam capacidades Internet com funções PSTN. As aplicações de telefonia IP habilitam a transmissão de tráfego de voz em tempo real através da infra-estrutura da Internet e a integração ininterrupta com a infra-estrutura PSTN existente. Embora a telefonia IP focalize primariamente em chamadas de voz, geralmente referidas como voz sobre IP ou VoIP, pode também ser usada para levar outras aplicações de faixa de voz ou multimídia, tal como fax, vídeo e modem de dados.
[00024] Um protocolo que foi desenvolvido para suportar telefonia IP é o Protocolo de Iniciação de Sessão (SIP). O SIP é um protocolo de sinalização para processar a configuração, modificação e interrupção de sessões multimídia, e em combinação com os protocolos com os quais é usado, descreve as características de sessão de uma sessão de comunicação para participantes potenciais da sessão. Estas sessões incluem conferências multimídia na Internet, chamadas telefônicas na Internet e distribuição de multimídia. Os convites SIP usados para criar sessões levam descrições de sessão que permitem que os participantes concordem com um conjunto de tipos de mídia compatíveis. SIP suporta mobilidade de usuário por requisições de proxy ou re-direcionamento à localização corrente de usuário. Usualmente, o Protocolo de Transporte em Tempo Real (RTP) é usado para trocar a
Petição 870180053298, de 20/06/2018, pág. 19/66 / 48 multimídia (áudio, voz ou dados) durante a sessão de comunicação, mas o SIP permite que qualquer protocolo de transporte seja usado. O SIP usa um modelo cliente-servidor, onde o cliente inicia requisições SIP e o servidor responde a requisições. No SIP, a entidade de ponto extremo é chamada Agente de Usuário, que é um cliente (Agente de Usuário de Cliente), isto é, o iniciador de uma requisição SIP, e um servidor (Agente de Usuário de Servidor) que retorna as respostas.
[00025] O SIP é disposto na Internet que pode ser considerada um ambiente hostil, nos quais os elementos SIP e mensagens podem ser expostos a uma variedade de ameaças de segurança e ataques. Em um sistema baseado no SIP, as medidas de autenticação podem ser habilitadas em diferentes camadas, incluindo a camada de aplicação, camada de transporte e camada de rede.
[00026] H. Tschofenig e outros, em “Using SAML para SIP”, transferido da Internet em 31 de Agosto de 2004 em http://ietf.org/internet-dratfs/drafttschofenig-sip-sam1-00-txt, propõe um método para usar a Linguagem de Marcação de Asserção de Segurança (SAML) em colaboração com o SIP, para acomodar um mecanismo de autorização. Um cenário de identidade assegurada de rede melhorada é descrito, no qual o melhoramento é baseado nos atributos declarados por um Serviço de Autenticação (AS). Um primeiro usuário que deseja se comunicar com um segundo usuário envia um INVITE SIP a seu AS preferido. Dependendo do mecanismo de segurança SIP escolhido, ou a autenticação condensada, S/MIME ou Segurança de Camada de Transporte é usada para prover o AS de uma forte segurança sobre a identidade do primeiro usuário. Após o primeiro usuário ser autenticado e autorizado, uma asserção SAML é anexada à mensagem SIP.
[00027] Como um número crescente de serviços começa a ser oferecido através da Internet, a capacidade de prover um mecanismo efetivo e seguro de assinatura único (SSO) para acesso a tais serviços tornou-se importante.
Petição 870180053298, de 20/06/2018, pág. 20/66 / 48
Serviços oferecidos através da Internet são freqüentemente distribuídos em diversos serviços que estão em localizações remotas uma relação à outra. Com um mecanismo SSO, um usuário pode autenticar sua identidade e autorização para usar diversos serviços distribuídos através dos diversos servidores remotos, através de um procedimento de autenticação executado em um ou em um número pequeno de servidores.
[00028] O pedido de patente WO No. 01/42009 descreve um mecanismo de autenticação SSO, no qual uma ficha é transmitida a um usuário que tenha requisitado autorização para acesso a um serviço. A ficha pode ser válida somente por um período de tempo. A funcionalidade relacionada à autenticação é separada dos serviços e a autenticação não precisa ser renegociada para acesso a um novo serviço, a partir dos diversos serviços, durante uma sessão. O usuário se registra para autorização para acesso ao serviço, comunicando suas credenciais, por exemplo, nome de usuário e senha, antes da ficha ser transmitida.
[00029] O Projeto de Aliança Liberty é uma organização padrão aberta para serviços de identidade federada e baseados em identidade. Provê um padrão para SSO que permite que um usuário assine uma vez em um site habilitado Liberty, sem a necessidade de autenticar novamente. “Liberty IDWSF - Web Services Framework” publicado em http://www.projectliberty.org/resources/whitepapers, oferece uma visão geral dos componentes Liberty ID-WSF. Os mecanismos de proteção de mensagem podem incluir mecanismos baseados em ficha tal como a propagação de uma asserção SAML em bloco de cabeçalho SOAP de acordo com a especificação de Segurança de Serviço da Web (WS-Security).
[00030] O pedido de patente WO No. 2004/06442 descreve um método e sistema de telecomunicação para prover serviços SSO para um usuário visitante em uma rede de rádio por pacote de uma operadora de rede móvel multinacional, que inclui uma federação de operadoras de rede nacional, uma
Petição 870180053298, de 20/06/2018, pág. 21/66 / 48 destas operadoras de rede nacionais mantendo a assinatura do usuário. O sistema de telecomunicação compreende adicionalmente um número de provedores de serviço que tenham assinado acordos de serviço com a federação de operadora de rede móvel multinacional para oferecer serviços SSO a usuários que são assinantes de alguma operadora de rede nacional incluída na federação. Cada provedor de serviço compreende meio para redirecionar um usuário para uma infra-estrutura de extremidade frontal SSO global como ponto de entrada na federação; meio para receber uma ficha do usuário, a ficha sendo uma asserção de autenticação (uma asserção SAML) ou uma referência desta; meio para recuperar uma asserção a partir de um site onde a asserção foi gerada e meio para verificar que tal site é acreditado.
[00031] O pedido de patente US 2003/0163733 descreve um sistema de telecomunicação compreendendo meio para redirecionar um usuário acessando um provedor de serviço, o usuário tendo uma assinatura com uma primeira operadora de rede móvel, na direção de um Broker @ de Autenticação de uma segunda possuindo um acordo com a citada segunda operadora de rede móvel operadora de rede móvel: A primeira e segunda operadoras de rede móvel pertencem a uma federação e o Broker @ de Autenticação atua como um ponto de entrada da federação na direção de um Provedor de Autenticação. Os usuários apresentam uma identidade não ambígua para seu Provedor de Autenticação para efetuar uma requisição de serviço SSO, por exemplo, MSISDN/IMSL.
Sumário da invenção [00032] A presente invenção relaciona-se a um método e sistema para autenticar um assinante de uma primeira rede para acessar serviços de aplicação, que são acessíveis através de uma segunda rede, que é uma rede de dados por pacotes (PDN). Os serviços de aplicação indicam serviços definidos no nível de aplicação, que podem ser representados neste contexto como o(s) nível(is) acima do nível de transporte. Em particular, o nível de
Petição 870180053298, de 20/06/2018, pág. 22/66 / 48 aplicação pode ser representado (de um modo não limitante) pela Camada 7, conforme definido no Modelo de Interconexão de Sistema Aberto (OSI) ou pelo Nível 5 de acordo com o modelo TCP/IP. Exemplos de serviços de aplicação são Serviços da Web, que são geralmente utilizados por uma aplicação de cliente usando protocolos tal como HTTP GET/POST, SMTP ou SOAP sobre HTTP, Sites da Web, que são tipicamente acessados através do uso de um navegador, ou VoIP.
[00033] O requerente observou que um assinante de uma primeira rede tal como a rede GSM é autenticado com segurança de alto nível dentro daquela rede.
[00034] O requerente observou adicionalmente que também no caso da primeira rede ser uma rede de acesso de linha fixa, a identidade do assinante pode ser validada com uma segurança de alto nível dentro daquela rede. No caso em que a rede de acesso fixa usa uma linha física compartilhada com a Rede Telefônica Comutada Pública (PSTN), tal como no caso da tecnologia xDSL, a comunicação entre o equipamento de premissas de usuário (CPE) e o ponto de conexão para a PDN usa um enlace com fio seguro e tipicamente dedicado, por exemplo, fio telefônico de cobre padrão ou fibra óptica.
[00035] Embora conexões sem fio, tais como conexões Wi-Fi®, tenham sido caracterizadas tradicionalmente por um nível de segurança relativamente baixo, devido ao enlace sem fio para a PDN, tem sido recentemente propostas soluções que garantem um nível de segurança relativamente alto do acesso de rede. Exemplos de soluções de alto nível de segurança são os padrões de segurança IEEE.802.11i, que são descritos, por exemplo, em “1EEE 802.11i and wireless security” por D.Halasz, transferido da Internet, em 20 de Setembro de 2005 em http://www.embedded.com/showArticle.jhtml?articleID=34400002.
[00036] O requerente verificou que uma identidade de assinante definida na primeira rede pode ser usada para autenticar o assinante no nível de
Petição 870180053298, de 20/06/2018, pág. 23/66 / 48 aplicação no qual o serviço de aplicação através da PDN opera. Em particular, de acordo com a invenção, o assinante pode ser autenticado de modo transparente para acessar um serviço de aplicação.
[00037] Em uma realização preferida da invenção, a primeira rede do assinante requisitando um serviço através de uma PDN é uma rede móvel comutada por pacote. Mais preferivelmente, a rede móvel comutada por pacote é o padrão GPRS com base no GSM. O PDN é normalmente uma rede externa à rede móvel, por exemplo, a rede IP. A invenção se aplica de modo similar ao caso em que o servidor de aplicação hospedando os serviços de aplicação é hospedado na mesma rede móvel a partir de onde o assinante inicia a sessão, mas o servidor é acessado através de uma PDN externa. Por exemplo, o servidor de aplicação pode ser em uma plataforma de Serviço de Valor Adicionado (VAS) de uma operadora móvel, que é provida por uma rede IP. Em particular, a PDN pode estar na rede privada ou rede pública do provedor de serviço.
[00038] Em uma outra realização da invenção, a primeira rede do assinante requisitando um serviço através de uma PDN, é uma rede de acesso fixa onde o assinante acessa a PDN usando o equipamento de premissas de usuário (CPE) tal como um modem DSL conectado a um PC ou um ponto de conexão residencial conectado a um dispositivo periférico, por exemplo, um conjunto portátil de telefone ou um “conversor de caixa de topo de aparelho” de TV. O CPE é conectado por enlace ascendente à rede de aceso fixa, por meio de uma linha física relativamente segura ou enlace sem fio, tal como uma linha telefônica dedicada, uma conexão de fibra óptica dedicada ou sem fio, com padrão de segurança IEEE802.11i embutido.
[00039] De acordo com uma realização preferida da invenção, a rede de acesso fixa é uma rede de acesso xDSL.
[00040] A requisição para acessar um serviço de aplicação posteriormente referida também como serviço, está na forma de uma mensagem de acesso
Petição 870180053298, de 20/06/2018, pág. 24/66 / 48 requerido definida no nível de aplicação.
[00041] Um aspecto da presente invenção relaciona-se a um método para autenticar um assinante de uma primeira rede para acessar serviços de aplicação através de uma segunda rede, onde a segunda rede é uma rede de dados por pacotes (PDN) e o acesso aos serviços de aplicação está na forma de mensagens de requisição de acesso incluídas em um pacote de dados, citado pacotes de dados incluindo um endereço na citada segunda rede alocada ao citado assinante (endereço do assinante) e citada mensagem de requisição de acesso expressa com uma sintaxe que é conforme a um protocolo de nível de aplicação, o método compreendendo as etapas de:
a) interceptar uma mensagem de requisição de acesso para a segunda rede;
b) reconhecer o protocolo de nível de aplicação;
c) prover o mapeamento entre o endereço do assinante e um primeiro identificador de assinante na primeira rede;
d) gerar uma primeira ficha de autenticação incluindo um segundo identificador de assinante;
e) associar a citada primeira ficha de autenticação à mensagem de requisição de acesso, e
f) transmitir a mensagem de requisição de acesso com a primeira ficha de autenticação associada à segunda rede.
[00042] Um outro aspecto da invenção relaciona-se a um sistema para autenticar um assinante de uma primeira rede para serviços de aplicação de acesso através de uma segunda rede, onde a segunda rede é uma rede de dados por pacotes (PDN), o citado sistema compreendendo uma estação de assinante acoplada à primeira rede e apta a gerar mensagens de requisição de acesso incluídas em pacotes de dados, citadas mensagens de requisição de acesso sendo expressas com uma sintaxe que é conforme a um protocolo de nível de aplicação;
Petição 870180053298, de 20/06/2018, pág. 25/66 / 48 um servidor de alocação, apto a alocar um endereço na citada segunda rede ao citado assinante (endereço do assinante) e a prover o mapeamento entre o endereço do assinante e um primeiro identificador do assinante na primeira rede;
um ponto de conexão apto a efetuar as seguintes funções: receber as mensagens de requisição de acesso da estação de assinante, para interfacear a primeira rede com a segunda rede e para designar o endereço do assinante à estação de assinante;
uma primeira entidade lógica conectada ao ponto de conexão e apta a interceptar os pacotes de dados gerados a partir da estação de assinante e direcionados à segunda rede, através do ponto de conexão, e para captura no pacote de dados de pelo menos um endereço do assinante, e uma segunda entidade lógica conectada à primeira entidade lógica e apta a executar as seguintes funções:
receber o endereço do assinante e a mensagem de requisição de acesso a partir da primeira entidade lógica, reconhecer o protocolo de nível de aplicação da mensagem de requisição de acesso, requisitar o primeiro identificador de assinante ao servidor de alocação; e gerar uma primeira ficha de autenticação de acordo com o protocolo de nível de aplicação, a citada ficha incluindo um segundo identificador de assinante, onde a primeira entidade lógica ou a segunda entidade lógica está apta a associar a ficha de autenticação à mensagem de requisição de acesso.
Breve descrição dos desenhos [00043] Figura 1 mostra uma realização da invenção na qual a primeira rede do assinante requisitando um serviço é um sistema GPRS, ao passo que a
Petição 870180053298, de 20/06/2018, pág. 26/66 / 48 segunda rede é uma rede IP.
[00044] Figura 2 relata um exemplo de uma tabela com a informação armazenada na Autoridade de Identidade (IA) de acordo com uma realização da invenção, onde a primeira rede é uma rede móvel.
[00045] Figura 3 ilustra o diagrama de processamento de uma operação de acesso para um Serviço da Web hospedado em um servidor de aplicação, de acordo com uma realização preferida da presente invenção.
[00046] Figura 4 ilustra um diagrama em blocos de uma rede comutada por pacotes conectada a uma rede externa NGN IP, de acordo com uma realização adicional da presente invenção.
[00047] Figura 5 ilustra esquematicamente o diagrama de processamento de uma operação de acesso através de um serviço NGN para um SIP hospedado em um servidor SIP de acordo com uma outra realização da invenção.
[00048] Figura 6 mostra o diagrama de processamento de uma operação de acesso para um site da Web hospedado em um servidor de aplicação, de acordo com um exemplo de uma realização preferida da presente invenção.
[00049] Figura 7 mostra uma realização alternativa da invenção na qual a primeira rede do assinante requisitando um serviço é uma rede fixa (ADSL), ao passo que a segunda rede é uma rede IP.
[00050] Figura 8 relata um exemplo de uma tabela com a informação armazenada na Autoridade de Identidade (IA) de acordo com uma realização da invenção, onde a primeira rede é uma rede fixa.
[00051] Figura 9 ilustra o diagrama de processamento de uma operação de acesso a um Serviço da Web hospedado em um servidor de aplicação, de acordo com uma outra realização preferida da presente invenção.
[00052] Figura 10 mostra uma realização da invenção na qual o usuário requisitando um serviço é um assinante de diversas (primeiras) redes, ao passo que a segunda rede é uma rede IP.
Petição 870180053298, de 20/06/2018, pág. 27/66 / 48 [00053] Figura 11 ilustra esquematicamente o diagrama de processamento em um contexto de autenticação mútua de acordo com uma realização adicional da invenção.
Descrição detalhada [00054] Figura 1 ilustra uma realização preferida da presente invenção. Na realização da Figura 1, a primeira rede é um sistema GPRS, ao passo que a segunda rede é uma rede IP 12. A realização da Figura 1 pode representar um cenário típico onde um assinante da rede GPRS deseja acessar a partir de sua estação móvel (MS) 2, através da rede IP, um serviço em um site da Web hospedado em um servidor de aplicação 11. Uma MS 2 é conectada via rádio a uma Estação de Transceptor Base (BTS) 3, que se conecta a um Controlador de Estação Base (BSC) 4. As funções combinadas da BTS e BSC são geralmente referidas como o Subsistema de Estação Base (BSS). A partir daí, o Nó de Suporte GPRS de Serviço (SGSN) 5 provê acesso ao GGSN, que serve como ponto de conexão para a rede de dados, neste caso a rede IP 12. O SGSN 5 efetua procedimentos de configuração de autenticação e cifragem, tipicamente baseado nos mesmos algoritmos, códigos, e critérios do GSM existente.
[00055] A MS 2, que pode ser um telefone móvel inclui um Módulo de Identidade de Assinante (SIM) que leva informação de identificação e autenticação por meio da qual a rede celular pode identificar o terminal MS dentro da rede celular e autorizá-la a funcionar na rede.
[00056] No sentido de enviar e receber dados GPRS, a MS 2 necessita ativar um endereço de dados de pacotes, isto é, nesta realização um endereço IP, que será usado para acessar o serviço. Quando o assinante requisita um serviço, a MS 2 necessita ativar um endereço de dados por pacotes, isto é, nesta realização um endereço IP, que será usado para acessar o serviço. Quando o assinante requisita um serviço, a MS 2 envia a requisição através da rede rádio, que termina no GGSN 6. Usando um protocolo específico, o
Petição 870180053298, de 20/06/2018, pág. 28/66 / 48
GGSN envia a requisição ao servidor de Conta de Autorização de Autenticação (AAA) 7 que é conhecido de per si. O servidor AAA pode ser, por exemplo, um servidor de Serviço de Usuário de Discagem de Autenticação Remota (RADIUS) ou um servidor de Protocolo de Configuração de Computador Principal Dinâmico (DHCP). No caso em que o servidor AAA é um servidor RADIUS, o GGSN inclui um cliente RADIUS de modo a usar o protocolo RADIUS para se comunicar com o servidor AAA. De acordo com o procedimento do padrão GPRS, o servidor AAA pode autenticar o assinante com base em qualquer número de atributos, tal como o Identificador de Acesso de Rede (NAI) ou o Identificador de Assinante Móvel Internacional (IMSI). O IMSI é um número de identificação que é univocamente associado a um assinante particular. O IMSI é geralmente designado pela operadora de rede móvel e efetua o rastreamento de cobrança e provisão de serviço a um possível assinante particular. O IMSI é geralmente levado no SIM.
[00057] Alternativamente, o Número ISDN Internacional de Estação Móvel (MSISDN) pode ser usado para identificar o assinante na rede móvel. Entretanto, uma vez que mais MSISDN, isto é, números telefônicos, podem ser associados ao mesmo IMSI, o IMSI é um identificador de assinante preferido (mas não limitante).
[00058] O servidor AAA aloca um endereço IP à MS e então o retorna ao GGSN. O GGSN designa o endereço IP à MS. O protocolo que é usado para designação de endereço é específico para redes GPRS, e é comumente denominado Ativação de Contexto PDP. A AAA contém uma base de dados onde os endereços IP alocados estão associados a uma identidade de assinante, por exemplo, o IMSI.
[00059] Deve ser entendido que, embora exemplos se refiram a um endereço IP alocado à MS 2, mais de um endereço IP pode ser alocado pelo GGSN à mesma MS. Naquele caso, de acordo com a especificação GPRS, o
Petição 870180053298, de 20/06/2018, pág. 29/66 / 48
GGSN pode armazenar a informação nas conexões ativas (contextos PDP) associadas à MS e pode verificar se o endereço IP usado pela MS em uma transmissão de pacote de dados é um dentre os endereços IP alocados pelo GGSN à MS.
[00060] Deve ser notado que o SGSN 5, GGSN 6 e AAA 7 da rede GPRS-GSM estão no mesmo domínio, o que é caracterizado pelo esquema de segurança GSM.
[00061] De acordo com uma realização preferida da presente invenção, uma entidade lógica (módulo de software) 10, posteriormente referido como Injetor de Ficha de Segurança (STI) é logicamente conectado ao GGSN 6. O STI é posicionado para controlar o tráfego de entrada a partir da rede GPRS/GSM. Em particular, o STI intercepta os pacotes de dados gerados a partir das estações móveis e direcionados à rede IP 12 através do GGSN 6.
[00062] Um pacote de dados, por exemplo, um pacote Internet, é um bloco de dados núcleo juntamente com informação anexada de endereço e administração, necessária, para permitir que a rede forneça os dados ao destino correto. O pacote de dados começa com os dados núcleo dados pela aplicação. Os dados núcleo são envelopados com várias camadas de cabeçalhos, onde as camadas podem ser descritas de acordo com o modelo OSI. Dentro desta descrição (não limitante), cada camada modifica o pacote de dados à medida que este passa, um mecanismo conhecido como encapsulamento. Os dados núcleo contém uma mensagem de nível de aplicação, que é expressa com uma sintaxe que é conforme a um protocolo de nível de aplicação. Exemplos de protocolos de nível de aplicação são FTP (Protocolo de Transferência de Arquivo), Protocolo de Transferência de Hipertexto (HTTP), SOAP (Protocolo de Acesso de Objeto Simples) ou SIP.
[00063] Uma mensagem de nível de aplicação requisitando o acesso a um serviço ou a uma funcionalidade ou operação de serviço é referida neste contexto como uma mensagem de requisição de acesso. Neste contexto, a
Petição 870180053298, de 20/06/2018, pág. 30/66 / 48 mensagem de requisição de acesso não descreve necessariamente uma requisição para ter acesso a um serviço na iniciação da sessão, porém também a requisição para acesso a uma funcionalidade ou uma operação provida por um serviço. Um exemplo de uma mensagem de requisição de acesso no SIP é a mensagem INVITE: quando um cliente de Agente de Usuário deseja iniciar uma sessão (por exemplo, áudio, vídeo ou um jogo) formula uma requisição INV1TE. A requisição INV1TE solicita a um servidor para estabelecer uma sessão (por exemplo, uma chamada de voz). Em um outro exemplo, quando é requisitada uma programa da Web, uma mensagem “get” é criada com a informação necessária para recuperar os dados desejados, por exemplo, o URL. O protocolo de nível de aplicação levando a mensagem “get” é, por exemplo, o HTTP. Neste caso, a mensagem “get” inclui um cabeçalho HTTP GET e é um exemplo de uma mensagem de requisição de acesso a um serviço (neste caso o serviço de recuperar uma programa da Web através da Internet) no nível de aplicação.
[00064] A pilha de protocolo na qual a Internet é executada pode ser descrita pela seqüência de protocolo Internet, que é também chamada seqüência TCP/IP, após os dois protocolos amplamente usados: o Protocolo de Controle de Transmissão (TCP) e o Protocolo Internet (IP). O conjunto de protocolos da seqüência TCP/IP cobre 5 camadas do modelo de camada OSI
7. Usando a seqüência TCP/IP, a mensagem é geralmente embutida em ambos cabeçalho de aplicação (que realmente compreende em geral vários cabeçalhos) e o corpo de nível de aplicação (ou carga útil). Os cabeçalhos estão em formato padronizado, de acordo com um protocolo de nível de aplicação, ao passo que a carga útil contém informação que é referente à aplicação, e dados não conformes aos cabeçalhos ou formato padrão. Exemplo de cabeçalhos no HTTP são o tipo de mensagem, tal como a mensagem GET e o URL da página da Web requisitada. A próxima camada é a camada de transporte, que adiciona uma camada de cabeçalhos comumente
Petição 870180053298, de 20/06/2018, pág. 31/66 / 48 definida no TCP ou no Protocolo de Datagrama de Usuário (UDP). Na camada de rede (conhecida na Internet também como a camada IP) o cabeçalho (o cabeçalho IP) contém a informação necessária para obter o pacote da fonte para o destino, incluindo os endereço de fonte e destino, isto é, os números de máquina.
[00065] O STI 10 opera pelo menos no nível de rede e captura os pacotes de dados saindo do GGSN 6. Se o STI opera somente no nível de rede ou somente até o nível de transporte, necessita capturar todos os pacotes de dados saindo do GGSN (e direcionados à rede IP), uma vez que não pode reconhecer as mensagens de aplicação levadas nos pacotes de dados, por exemplo, se esta é uma mensagem de requisição de acesso e em cujo protocolo de nível de aplicação a mensagem é levada. No caso do STI operar também no nível de aplicação, este pode reconhecer as mensagens de requisição de acesso e discriminar os diferentes protocolos de nível de aplicação. Por exemplo, caso operando também no nível de aplicação, o STI pode ser programado para interceptar somente as mensagens de requisição de acesso SIP e deixar passar mensagens codificadas em outros protocolos.
[00066] Uma das tecnologias que pode ser usada para realização do módulo STI é a de uma barreira de proteção no nível de aplicação. Exemplos de barreiras de proteção de aplicação comercial são Cisco PIX, Check Point Firewall-1® e Xtradyne's WS-DBC.
[00067] A informação mínima que o STI tem que interceptar em um pacote de dados levando uma mensagem de requisição de acesso é a informação no nível da rede sobre o endereço do assinante, por exemplo, na Internet o endereço IP alocado ao assinante (isto é, à MS). Em geral, o STI necessitará de informação sobre o endereço de destino para transmitir pacote de dados levando a mensagem ao final do processo de autenticação, conforme explicado abaixo em mais detalhe. Preferivelmente, esta informação é extraída pelo STI ao interceptar o pacote de dados. Isto é entretanto, uma
Petição 870180053298, de 20/06/2018, pág. 32/66 / 48 característica não limitante, pois o STI poderia ser configurado para transmitir as mensagens para endereço(s) de destino, que o sistema de autenticação tenha definido. Deve ser notado que o endereço de destino não é necessariamente o endereço do servidor de aplicação através do qual a mensagem é direcionada. Por exemplo, de acordo com o protocolo SIP, mensagens podem ser direcionadas a um proxy SIP que então endereçará a mensagem ao servidor de aplicação conforme especificado no endereço de nível de aplicação incluído no cabeçalho da mensagem.
[00068] Pelo menos parte da informação contida nos pacotes de dados capturados pelo STI 10 é passada a um componente de software 9, referido como Autoridade de Identidade (IA) que opera no nível de aplicação. A IA é responsável pelo gerenciamento da identidade dos assinantes acessando o PDN externo, isto é, rede IP 12. A IA recebe do STI pelo menos um endereço IP do assinante e a informação sobre o protocolo de nível de aplicação da mensagem de requisição de acesso. A última informação pode ser obtida recebendo o pacote de dados do STI (como um “envelope fechado” se o STI opera apenas até o nível de rede/transporte) ou, se o STI opera também no nível de aplicação, recebendo informação específica tal como o tipo de protocolo (por exemplo, SOAP, HTTP, SIP). Outras informações recebidas de um nível de aplicação de operação STI podem incluir o tipo de mensagem (por exemplo, INVITE ou REGISTER) e o Identificador de Recurso Universal (URI) dos serviços requeridos, por exemplo, o URL de uma página da Web.
[00069] A IA 9 identifica a estação móvel MS 2 (isto é, o assinante) que requisita um serviço obtendo o conhecimento de seu endereço IP a partir do STI 10 e obtendo conhecimento da identidade do assinante interrogando a AAA 7, que contém o mapeamento entre os endereço IP alocados e uma identidade (ou identidades) do assinante. Como identidade de assinante, o MSI é preferivelmente extraído pela IA.
[00070] Preferivelmente, a IA armazena a informação relativa à
Petição 870180053298, de 20/06/2018, pág. 33/66 / 48 identidade do assinante e ao serviço que requisita. A informação sobre o serviço requisitado pode ser o endereço IP e/ou o URI do provedor de serviço, e/ou o protocolo usado pelo serviço, no caso do provedor de serviço oferecer mais serviços utilizando diferentes protocolos (por exemplo, POP3 para conta de e-mail e HTTP para navegação da Web). Na Figura 2, um exemplo de uma tabela com a informação armazenada na IA é relatado. A tabela ilustrada provê um mapeamento para assinantes A, B e C, quem desejar acessar um ou mais serviços caracterizado pelo provedor de serviço SP-1, SP-2, etc. No exemplo da Figura 2, os assinantes são identificados por seu IMSI. Preferivelmente, um pseudônimo PS é criado para a IA para cada assinante, por exemplo, um PS correspondente a um IMSI do assinante, é criado. Alternativamente, conforme relatado na Figura 2, mais pseudônimos podem ser gerados para um assinante, alternativamente, conforme relatado na Figura 2 mais pseudônimos podem ser gerados para um assinante, onde cada pseudônimo caracteriza um serviço específico requisitado pelo assinante. A criação de pseudônimos é preferida, no sentido de evitar descrever dados sensíveis, tal como o MSI, como se tornará mais claro a seguir.
[00071] Após ter verificado a identidade do assinante, por exemplo, mapeando o endereço IP com o IMSI associado ao assinante, a IA gera uma ficha de software de acordo com o protocolo de nível de aplicação da mensagem de requisição de acesso. Por exemplo, em um caso de uma mensagem SOAP para um Serviço da Web, a ficha pode ser definida de acordo com a especificação de Segurança WS. A ficha é inserida na mensagem de requisição de acesso, por exemplo, como um campo inserido em um cabeçalho de aplicação existente da mensagem, ou como um novo cabeçalho de aplicação adicionado na mensagem.
[00072] Dependendo de em qual nível o STI opera, ou a ficha pode ser inserida na mensagem pela IA, ou a IA pode solicitar ao STI para inserir a ficha na mensagem. A última opção supõe que o STI opera também no nível
Petição 870180053298, de 20/06/2018, pág. 34/66 / 48 de aplicação. Em qualquer caso, o STI envia a mensagem de requisição de acesso modificada, isto é, contendo a ficha, ao servidor de aplicação 11, que recebe uma mensagem autenticada.
[00073] A autenticação da mensagem pode ser reconhecida pelo serviço de aplicação (executando no servidor de aplicação 11) por exemplo por um software de servidor de aplicação que verifica a ficha e então a envia na lógica de aplicação do serviço. Um exemplo de estrutura de trabalho controlando a autenticação é o Gerenciador de Acesso de Sistema Sun Java, que é uma arquitetura baseada em uma plataforma Java 2 aberta.
[00074] A ficha de autenticação inclui um identificador do assinante associado a uma identidade do assinante definida na rede móvel, tipicamente no domínio da operadora móvel, tal como IMSI ou MSISDN.
[00075] Preferivelmente, o identificador do assinante incluído na ficha é um pseudônimo associado a uma identidade baseada no SIM, por exemplo, o IMSI ou o MSISDN. O uso de pseudônimo protege a privacidade do assinante é evita a descrição de informação sensível, tal como o IMSI, no sentido de evitar ameaças de segurança (por exemplo, fraude no processo de cobrança da operadora móvel), embora a presente invenção não exclua o uso de uma identidade de assinante definida na rede móvel na ficha de autenticação. Alternativamente, o identificador pode ser um caracter/código de autorização designado pela operadora móvel a um assinante, na dependência, por exemplo, de seu crédito. Embora seja preferido que o identificador corresponda univocamente a uma identidade do assinante, o mesmo caracter/código de autorização pode ser designado para um grupo de assinantes, por exemplo, agrupado por idade.
[00076] Opcionalmente, a IA passa a ficha gerada, antes de transmiti-la ao STI, para um serviço de Infra-estrutura de Código Público (PKI) 8, que certifica a ficha, por exemplo, adicionando uma assinante digital à ficha, por meio de criptografia assimétrica, que é conhecida por si só. A PKI 8 pode ser
Petição 870180053298, de 20/06/2018, pág. 35/66 / 48 uma estrutura de trabalho comercial, como Entrust PKI ou VeriSign® ou uma ferramenta fonte gratuita/aberta como OpenSSL.
[00077] O sistema de autenticação da presente invenção tem a vantagem de ser transparente ao assinante que, após ter requisitado um serviço, vê somente o resultado da autenticação: ou o acesso ao serviço ou uma rejeição de acesso.
[00078] A plataforma de software de autenticação contendo STI e IA pode ser sob o controle direto da operadora da rede móvel.
[00079] Embora mostrados como componentes externos separados do GGSN 6, o STI 10 e a IA 9 podem ser implementados dentro do GGSN, por exemplo, como módulos de software que estão embutidos na lógica de controle do padrão GPRS do GGSN. Isto pode melhorar a segurança do STI contra ataques no nível da rede, uma vez que isto eliminaria a conexão física entre o GGSN e o STI.
[00080] Os módulos STI e IA podem ser componentes de software realizados em linguagens padrão, tais como Java, C, C++ e CORBA e instalados em componentes de hardware conhecidos de per si.
[00081] A Figura 3 ilustra o diagrama de processamento de uma operação de acesso a um Serviço da Web hospedado no servidor de aplicação, de acordo com uma realização preferida da presente invenção. Os componentes principais interagindo no fluxo do processo representado na Figura 3 possuem as mesmas funções lógicas daqueles descritos com referência à Figura 1 e são indicados pelo mesmo número de referência.
[00082] Na realização ilustrada na Figura 3, a MS 2 pode ser um telefone celular incluindo um cliente habilitado para dados para a conexão e transferência de dados dentro de uma rede celular comutada por pacotes, tal como GPRS, EDGE ou UMTS. Por exemplo, o telefone celular pode ser conectado (com um enlace com fio ou sem fio) a um computador pessoal que utiliza o telefone para a conexão à rede comutada por pacotes. O servidor de
Petição 870180053298, de 20/06/2018, pág. 36/66 / 48 aplicação 11 está hospedado em um domínio que é externo à rede celular, a qual está conectada ao servidor através de uma rede IP pública.
[00083] Na Figura 3, a MS requisita o acesso a um serviço “abc” oferecido na rede IP pública, usando, por exemplo, o protocolo SOAP, que é uma linguagem baseada em XML usada para passar dados para e a partir de um Serviço da Web. A mensagem SOAP pode estar contida em uma mensagem HTTP (no nível da aplicação). Uma requisição SOAP poderia ser, por exemplo, uma requisição HTTP POST ou uma requisição HTTP GET no cabeçalho, ao passo que a mensagem SOAP está contida, por exemplo, no corpo da mensagem. Na Figura 3, é dado o exemplo de uma HTTP POST, a saber “POST /abc HTTP/1.1”. A etapa 31 representa, de uma maneira simplificada a interação entre a MS 2 e o GGSN 6, necessário para a MS obter acesso à rede externa. Durante a etapa 31, a MS é identificada e autorizada por AAA 7, que aloca um endereço IP à MS e armazena na memória a informação de mapeamento entre o endereço IP e uma identidade do assinante, pelo menos pela duração da sessão de dados. Nesta realização, a identidade do assinante compreende o IMSI. Após a fase de autorização e autenticação dentro da rede celular da etapa 31, a mensagem de requisição de acesso levada em um pacote de dados é enviada pelo GGSN à rede externa (etapa 32). A linha tracejada da etapa 32 representa o caminho lógico que a mensagem teria percorrido sem o mecanismo de autenticação, de acordo com a presente invenção, isto é, a mensagem teria sido transmitida ao servidor de aplicação 11 que deveria ter então desafiado o usuário por meio de um mecanismo de desafio/resposta para autenticação.
[00084] De acordo com a presente invenção, na etapa 32 o pacote de dados abrangendo a mensagem de requisição de acesso é interceptado pelo STI 10, que está localizado entre o GGSN 6 e a rede pública. O STI extrai do pacote de dados interceptado o endereço IP do assinante, isto é, o endereço alocado à MS para a sessão, e preferivelmente o endereço do destino IP, isto
Petição 870180053298, de 20/06/2018, pág. 37/66 / 48 é, o endereço do servidor de aplicação 11. O STI então envia a mensagem de aplicação (neste caso uma mensagem SOAP) e o endereço IP do assinante à IA 9 (etapa 33).
[00085] Se o STI opera em níveis mais baixos que o nível de aplicação, a mensagem é automaticamente redirecionada à IA, por exemplo, enviando o(s) cabeçalho(s) da aplicação na direção da IA. Inversamente, se o STI opera no nível da aplicação, este reconhece o protocolo usado na mensagem de nível de aplicação, neste caso a SOAP sobre o protocolo HTTP. Em qualquer caso, a IA obtém conhecimento do endereço IP do assinante e do protocolo de nível de aplicação ao qual a mensagem é conforme. A transmissão de informação entre o STI e a IA pode, por exemplo, ocorrer por meio de interfaces especificadas na Arquitetura Broker @ de Requisição de Objeto Comum (CORBA), tais como a Linguagem de Definição de Interface (IDL) ou em linguagens de Serviços da Web, tais como a Linguagem de Descrição de Serviço da Web (WSDL).
[00086] Na etapa 34, a IA 9 interroga a AAA 7 para determinar uma identidade do assinante (conectado à rede celular por meio da MS 2) na rede GSM, citada identidade correspondendo ao endereço IP fonte capturado no pacote de dados. Na etapa 35, a AAA 7 responde à interrogação provendo a IA de uma identidade de assinante, neste caso representada pelo IMSI, associada ao endereço IP.
[00087] Na próxima etapa (etapa 35), a IA gera uma ficha incluindo um identificador do assinante. A ficha, por exemplo uma cadeia de caracteres, pode ser definida, por exemplo, de acordo com a especificação de Segurança WS (indicada na Figura 3 como <WS>token). Preferivelmente, o identificador incluído na ficha é um pseudônimo criado pela IA e associado ao IMSI. O identificador pode ser também associado ao provedor de serviço como no exemplo ilustrado na Figura 2, tal como no caso em que mais pseudônimos são criados para o mesmo assinante, isto é, o mesmo IMSI, para
Petição 870180053298, de 20/06/2018, pág. 38/66
28/48 acessar diferentes serviços dentro de uma sessão, como no caso de um mecanismo de acesso de assinatura única (SSO). A IA não perde de vista o mapeamento entre o(s) pseudônimo(s) e a identidade de assinante definida na rede celular (isto é, o IMSI), pelo menos pela duração da sessão.
[00088] O exemplo seguinte é uma ficha (simplificada) SAML expressa em formato XML e conforme ao padrão aberto OÁSIS (Organização para o Avanço de padrões de Informação Estruturada):
csamljAssertion Major’Verslon=l‘'
AssertionlD^Ha . 9.167.32.12345678”
I s suer = Operat or . cotti < IssueInstaEit=20D4-12-U311lÜ íOSíDOZ > <eaml: Condi ti ous
WotBefore= *2004-12-03T1Ü : 0 0 s 0 0 Ξ” notAfter= 2004-12-03T1Ü : 0 5 !θΟΖ/> <&amL i Aut hsnt i CcttiQnSt a temera t Autlienticat.ionMethod=
Autlient i ca tlcm Instante20 01— 12-03110 ; 02: 003 >
-íSàiril = Subj act>
<samltNameldentifier
SecurityDomãin= operator. com Hame='LFãt;UE>C»NYf'1 />
</samlisübject>
ΐ/saml íAuthenticatioaStat emenl>
</'saml :Assezt £ [00089] A ficha SAML do exemplo acima assegura a identidade do usuário cujo nome é “PSEUDÔNIMO” isto é, o identificador dado pela IA) que está associado a uma identidade definida a rede GSM. Preferivelmente, a ficha SAML contém a informação sobre o método de autenticação usado para autorizar o acesso ao serviço, que é neste caso definida pelo esquema de segurança GSM (indicado por <GSM>). Informação opcional adicional é o emissor da autenticação (indicado por operator.com) e as condições de validade da ficha (indicadas pelos comandos NotBefore e NotAfter).
[00090] Opcionalmente, a ficha é enviada ao serviço PKI 8 para afixar uma assinante digital à ficha ou para criptografá-la de acordo com mecanismos de criptografia conhecidos (etapa 36). Na etapa 37, a PKI retorna
Petição 870180053298, de 20/06/2018, pág. 39/66 / 48 a ficha, ou certificado com uma assinatura digital e/ou assegurada por meio de criptografia. A ficha certificada/criptografada é indicada na Figura 3 por DS (<WS>-token).
[00091] Em seguida à etapa 35, (ou etapa 37 se o serviço PKI é incluído) a IA cria uma nova mensagem de requisição de acesso, indicada por “Newsoap”, que inclui a ficha gerada. Preferivelmente, a nova mensagem é a mensagem de requisição de acesso transmitida a partir da MS na qual a ficha foi adicionada no envelope SOAP como um campo adicional conforme descrito na especificação de Segurança WS OASIS. Na etapa 38, a nova mensagem de requisição de acesso (incluindo a ficha) é passada ao STI para a transmissão. O STI, que copiou previamente e armazenou em sua memória o pacote de dados a partir do qual a informação foi extraída, então transmite a mensagem de requisição de acesso recebida ao servidor de aplicação 11 (etapa 39).
[00092] Se uma assinatura digital foi afixada à ficha, o servidor de aplicação verifica a assinatura digital, interrogando o serviço PKI (etapa 40). Por exemplo, a PKI verifica que o certificado da assinatura digital da ficha é válido.
[00093] Finalmente, o servidor de aplicação 11, que recebeu a autenticação da identidade do assinante por meio da ficha, provê ao assinante autenticado o serviço requisitado (etapa 41).
[00094] Deve ser notado que o mecanismo de autenticação descrito na Figura 3 é transparente ao usuário que não necessita inserir credenciais para acessar o serviço. Em adição, o mecanismo de autenticação permite um acesso transparente a diversos serviços com um mecanismo SSO, que geralmente pressupõe que exista um acordo entre provedores de serviço oferecendo os serviços (federação de identidade).
[00095] Figura 4 ilustra um diagrama em blocos de uma rede comutada por pacotes conectada a uma rede IP externa, de acordo com uma realização
Petição 870180053298, de 20/06/2018, pág. 40/66 / 48 adicional da presente invenção. Uma MS 2 é conectada via rádio a uma rede móvel comutada por pacotes 13, por exemplo, uma rede UMTS. Embora não mostrado em detalhe, a rede móvel 13 inclui um servidor AAA e um GGSN. A rede IP é, nesta realização, uma Rede da Próxima Geração (NGN) 15, uma rede baseada em pacotes que permite a convergência entre a Internet baseada em pacote e as redes de telefonia, e suporta todos os tipos de tráfego de usuário incluindo voz, dados e vídeo. Uma aplicação da tecnologia NGN é a Voz sobre IP (VoIP). De acordo com a realização ilustrada na Figura 4, um telefone móvel MS 2 endereça uma mensagem SIP a um servidor SIP 4 através de uma NGN 15. As mensagens SIP saindo do GGSN da rede móvel 13 são interceptadas pela plataforma de autenticação 17. A plataforma de autenticação 17 inclui um STI 10, uma IA 9 e opcionalmente uma PKI 8, que possuem as mesmas funções lógicas gerais descritas com referência à Figura
1. Após autenticação, o servidor SIP 14 envia a mensagem SIP sempre através da NGN 15, até um telefone SIP 16, que é um nó IP incluindo uma aplicação de cliente para efetuar e receber chamadas (por exemplo, um cliente de Agente de Usuário e um servidor de Agente de Usuário) para e a partir de outros telefones, ou telefones celulares baseados em IP ou de linhas terrestres, e que podem ser instalados, por exemplo, em um computador pessoal. Um exemplo de mensagem SIP é a requisição originada de um telefone móvel 2 para configurar uma chamada multimídia (por exemplo, uma vídeoconferência) com o telefone SIP 16.
[00096] O diagrama de processamento de uma operação de acesso através de uma NGN para um serviço SIP hospedado em um servidor SIP, é ilustrado esquematicamente na Figura 5. A MS 2 requisita o acesso a um serviço oferecido na NGN, usando o protocolo SIP. Por exemplo, o serviço é a configuração de uma sessão de vídeo-conferência, que pode ser requisitado por um comando NV1TE. A mensagem SIP pode ser, por exemplo, sip:[email protected] SIP/2.0”, onde [email protected] é o Request_IRI, que
Petição 870180053298, de 20/06/2018, pág. 41/66 / 48 é um SIP URI (por exemplo, um URL) que especifica o destino da mensagem SIP. O Request_URI pode ser um usuário ou um servidor de Agente de Usuário definido no telefone SIP. Neste exemplo, o Request_URI é um usuário identificado pelo telefone SIP 16. A mensagem SIP pode ser transportada no nível da rede pelo TCP ou UDP.
[00097] A etapa 50 representa de uma maneira simplificada a interação entre a MS 2 e o GGSN 6, necessária para a MS obter acesso à rede externa. Durante a endereço IP 50, a MS é identificada e autorizada pela AAA 7, que aloca um endereço IP à MS e armazena na memória a informação de mapeamento entre o endereço IP e a identidade do assinante, por exemplo, o IMSI, pelo menos pela duração da sessão de dados. Após a fase de autorização e autenticação dentro da rede móvel, da etapa 50, a mensagem de requisição de acesso levada em um pacote de dados é enviada pelo GGSN à rede externa (etapa 51). A linha tracejada da etapa 51 representa o caminho lógico que a mensagem teria percorrido sem o mecanismo de autenticação de acordo com a presente invenção, isto é, a mensagem teria sido transmitida ao servidor SIP 14.
[00098] De acordo com a presente invenção, na etapa 52 a mensagem SIP é interceptada pelo STI 10, que está localizado entre o GGSN e a NGN. O STI extrai do pacote de dados interceptado o endereço IP fonte (isto é, o endereço alocado à MS) e endereço IP de destino, isto é, o endereço do servidor SIP que pode processar a requisição e enviar a mensagem NV1TE ao callee @ correto (indicado pelo SIP URI). O STI então envia a mensagem SIP e o endereço IP do assinante à IA 9 (etapa 52).
[00099] Na etapa 53, a IA 9 interroga a AAA 7 para determinar uma identidade de assinante correspondente ao endereço IP fonte capturado no pacote de dados contendo a mensagem SIP. Na etapa 54, a AAA 7 responde à interrogação provendo a IA da identidade do assinante, neste caso representada pelo IMSI, associado ao endereço IP.
Petição 870180053298, de 20/06/2018, pág. 42/66 / 48 [000100] Na próxima etapa (etapa 54), a IA gera uma ficha incluindo um identificador do assinante. A ficha pode ser, por exemplo, definida de acordo com a especificação SAML (indicada na Figura 5 como [SAML]token). Preferivelmente, o identificador é um pseudônimo criado pela IA e associado ao IMSI.
[000101] Opcionalmente, a ficha é redirecionada ao serviço PKI 8 para afixar uma assinatura digital à ficha e/ou para criptografá-la de acordo com mecanismos de criptografia conhecidos (etapa 55). Na etapa 56, a PKI retorna a ficha certificada com uma assinatura digital e/ou assegurada por meio de criptografia. A ficha certificada/criptografada é indicada na Figura 5 por DS( [SAML]-token ).
[000102] Em seguida à etapa 54 (ou etapa 56 se o serviço PKI estiver incluído), a IA cria uma nova mensagem de requisição de acesso, indicada por “Novo cabeçalho SIP”, que inclui a ficha gerada. Preferivelmente, a nova mensagem é a mensagem de requisição de acesso transmitida a partir da MS, na qual a ficha tenha sido adicionada no cabeçalho SIP como um campo adicional descrito no protocolo SIP, conforme ilustrado na Figura 5 pelo cabeçalho SIP 61. O campo “Carga útil SAML” precedendo DS ([SAML]token) é uma palavra chave definida pelo IETF e é usado para identificar o cabeçalho de ficha SAML.
[000103] A nova mensagem de requisição de acesso (incluindo a ficha) é passada ao STI para a transmissão (etapa 57). O STI então direciona a mensagem SIP 61 recebida ao servidor SIP (etapa 58).
[000104] Se uma assinatura digital foi afixada à ficha, o servidor de aplicação verifica a assinatura digital, interrogando o serviço PKI (etapa 59).
[000105] Finalmente, o servidor de aplicação 14, que tinha recebido a autenticação da identidade de assinante por meio da ficha, transmite uma resposta positiva à mensagem INVITE, enviando uma mensagem “200 OK” à MS (etapa 60), que é uma resposta positiva SIP padrão à mensagem INVITE.
Petição 870180053298, de 20/06/2018, pág. 43/66 / 48
Um fluxo de áudio-vídeo usando RTP pode então ser estabelecido entre pontos de extremidade.
[000106] Referindo-se de volta à Figura 4, embora ilustrada como externa à rede móvel, a plataforma de autenticação 17 pode ser implementada na rede móvel comutada por pacotes 13, isto é, no domínio de segurança da operadora móvel.
[000107] Figura 6 mostra o diagrama de processamento de uma operação de acesso a um site da Web hospedado em um servidor de aplicação, de acordo com um exemplo de uma realização preferida da presente invenção. O acesso ao site da Web é a partir de rede móvel de circuito comutado, tal como GSM, ou a partir de GPRS, que são conectados à rede IP usando Protocolo de Aplicação Sem Fio (WAP). De acordo com a presente realização, a MS 2, por exemplo, um telefone GSM, abrange um micro navegador que interpreta os dados WAP. Estes dados WAP são enviados usando um protocolo de rede tal como UDP. O servidor de aplicação pode ser um servidor WAP dedicado ou servidor da Web tradicional. As funções lógicas de ponto de conexão da rede celular para as redes externas são executadas por um GGSN 6.
[000108] A realização ilustrada na Figura 6 pode ser, por exemplo, aplicada à Estrutura de Trabalho de Federação de Identidade (ID-FF) definida pelo Projeto de Aliança Liberty. A ID-FF é baseada no padrão SAML e provê autenticação baseada no padrão SOAP e interfaces de serviço de assinatura única a um provedor de identidade.
[000109] Na Figura 6, a MS 2 requisita o acesso a um serviço “abc” oferecido na rede IP pública usando, por exemplo, o protocolo HTTP. Na Figura 6, é dado o exemplo de uma requisição GET HTTP, a saber “GET /abc HTTP/1.1”. A etapa 71 representa de uma maneira simplificada a interação entre a MS 2 e o GGSN, necessária para a MS obter acesso à rede externa. Durante a etapa 71, a MS é identificada e autorizada pela AAA 7, que aloca um endereço IP à MS e armazena na memória a informação de mapeamento
Petição 870180053298, de 20/06/2018, pág. 44/66 / 48 entre o endereço IP e uma identidade de assinante, pelo menos pela duração da sessão de dados. Nesta realização, a identidade do assinante compreende o IMSI. Após a fase de autorização e autenticação dentro da rede celular da etapa 71, a mensagem de requisição de acesso levada em um pacote de dados é redirecionada pelo GGSN para a rede externa (etapa 72). A linha tracejada da etapa 72 representa o caminho lógico que a mensagem teria percorrido sem o mecanismo de autenticação de acordo com a presente invenção, isto é, a mensagem teria sido transmitida ao servidor Web/WAP.
[000110] De acordo com a presente invenção, na etapa 72 o pacote de dados englobando a mensagem de requisição de acesso é interceptado pelo STI 10, que está localizado entre o GGSN e a rede pública. O STI extrai do pacote de dados interceptado o endereço IP do assinante, isto é, o endereço alocado à MS para a sessão, e o endereço de destino IP, isto é, o endereço do servidor de aplicação 11. O STI então envia a mensagem de aplicação (neste caso uma mensagem HTTP GET) e o endereço IP do assinante à IA 9 (etapa 73).
[000111] Na etapa 74, a IA 9 interroga a AAA 7 para determinar uma identidade do assinante (conectado à rede celular por meio da MS 2), citada identidade correspondendo ao endereço IP fonte capturado no pacote de dados. Na etapa 75, a AAA 7 responde à interrogação provendo a IA de uma identidade de assinante, neste caso representada pelo IMSI, associada ao endereço IP.
[000112] Na próxima etapa (etapa 76), a IA gera uma ficha incluindo um identificador do assinante. Preferivelmente, o identificador incluído na ficha é um pseudônimo criado pela IA e associado ao IMSI. A ficha pode ser, por exemplo, definida de acordo com a especificação SAML (indicada na Figura 6 como [SAML]-token). Preferivelmente, o identificador é um pseudônimo criado pela IA e associado ao IMSI.
[000113] Opcionalmente, a ficha é enviada ao serviço PKI 8 para afixar
Petição 870180053298, de 20/06/2018, pág. 45/66 / 48 uma assinatura digital à ficha e/ou para criptografá-la de acordo com mecanismos de criptografia conhecidos (etapa 76). Na etapa 77, a PKI retorna a ficha certificada com uma assinatura digital e/ou assegurada por meio de criptografia. A ficha certificada/criptografada é indicada na Figura 5 por DS ( [SAML]-token ).
[000114] Em seguida à etapa 54 (ou etapa 56 se o serviço PKI estiver incluído), a IA cria um “artefato” que atua como um indicador para a asserção SAML de acordo com um padrão definido pela Aliança Liberty. Citado artefato é indicado na Figura 6 por “Artefato(SAML)”. O artefato é então provido ao STI na etapa 78. Na etapa 79, o STI envia a mensagem HTTP GET contendo o “Artefato(SAML)” ao servidor Web/WAP. Durante a etapa 80, o servidor que recebeu a mensagem de requisição de acesso contendo o artefato, requisita à IA para prover a ficha SAML correspondente ao artefato. Após ter recebido a ficha SAML incluindo um identificador do assinante móvel fazendo a requisição, o assinante é identificado (e autorizado) e o servidor (isto é, o provedor de serviço) envia então uma resposta positiva de “bem-vindo” à MS (etapa 81).
[000115] Figura 7 ilustra uma outra realização preferida da invenção na qual a primeira rede do assinante requisitando um serviço é uma rede de acesso ADSL, ao passo que a segunda rede é uma rede IP. A realização da Figura 7 pode representar um cenário típico onde um assinante da rede ADSL deseja acessar a partir de seu computador pessoal (PC) 18, através da rede IP, um serviço em um site da Web hospedado em um servidor de aplicação 24. Neste exemplo, o PC 18 é conectado a um modem ADSL 19 através de uma interface USB (Barramento Serial Universal) serial padrão. O PC 18 e o modem ADSL 19 são geralmente referidos como equipamento de premissas de usuário (CPE) 68. Entretanto, podem ser considerados CPE alternativos, tais como um ponto de conexão residencial conectado a um ou mais PC, fones IP ou a um “conversor de caixa de topo de equipamento” de TV. Portanto, em
Petição 870180053298, de 20/06/2018, pág. 46/66 / 48 geral um CPE é empregado para originar, rotear ou terminar telecomunicações e para prover requisição de autenticação para acessar uma PDN, por exemplo, teclando um ID de acesso e senha a partir de um teclado do PC ou por autenticação automática a partir de um ponto de conexão residencial (por exemplo, por meio de um código de caracter incluído em um cartão inteligente ou embutido no firmware do ponto de conexão residencial). É enfatizado que esta autenticação está dentro da rede de acesso para autorizar o acesso a uma PDN (por exemplo, Internet).
[000116] O assinante é conectado via um CPE 68 a um multiplexador de acesso DSL (DSLAM) 30. O DSLAM 30 inclui um multiplexador/demultiplexador e a linha de usuário (por exemplo, enlace com fio 67) se conecta a uma unidade terminal ADSL designada dentro do DSLAM no escritório central (premissas de operador) 66. O DSLAM 30 se conecta em enlace ascendente a um servidor de acesso de rede de faixa larga (BNAS) 29, que provê o gerenciamento de sessão de nível de aplicação incluindo roteamento ou seleção de serviço. O CPE reside na localização do usuário final (por exemplo, residência ou escritório), que é esquematicamente indicada na Figura 7 pelo número de referência 20. A conexão entre o CPE e o DSLAM é um enlace com fio 67, geralmente uma linha telefônica de cobre padrão. A telefonia analógica convencional, isto é, sistema telefônico antigo comum (POTS) 23, pode ser opcionalmente conectado com uma PSTN 25 através do mesmo enlace com fio 67. Portanto, o enlace com fio 67 pode levar ambos os sinais POTS e DSL. O BNAS 29, juntamente com o DSLAM 30 funciona como ponto de conexão para uma rede de dados por pacotes externa, neste caso a rede IP 22. É importante notar que a comunicação entre o CPE e o DSLAM um enlace com fio dedicado entre as premissas de usuário e o escritório central, assegurando deste modo um alto nível de segurança das comunicações dentro da infra-estrutura DSL.
[000117] O BNAS processa a autenticação do assinante requisitando para
Petição 870180053298, de 20/06/2018, pág. 47/66 / 48 acessar a rede IP, de modo a autorizar o acesso ao assinante. A autenticação de conexão é realizada por um servidor de autenticação, autorização e conta (AAA) 26. O servidor AAA 26 executa operações lógicas similares àquelas do servidor AAA da rede móvel descrita na realização da Figura 1. Em particular, o servidor AAA contém uma base de dados onde o endereço IP alocado está associado a uma identidade de assinante dentro da rede xDSL. De acordo com métodos conhecidos, a autenticação para acessar a PDN, que pode ser referida como autenticação de conexão, pode ser baseada em mecanismos de senha, cartões inteligentes ou fichas criptografadas. O mecanismo de autenticação de conexão preferido usa um ID de conexão, geralmente um nome de usuário associado a uma senha, que é inserido pelo assinante ao requisitar uma conexão para uma rede de dados externa. O ID de conexão pode também estar incluído em um cartão inteligente. O uso de um ID de conexão permite a discriminação entre diferentes usuários que podem empregar a mesma estação de assinante, por exemplo, usuários que se conectam através do mesmo PC. Alternativamente, o assinante pode ser identificado dentro da infra-estrutura ADSL pela identificação de linha chamadora (CLI) da PSTN.
[000118] De acordo com a invenção, um Injetor de Ficha de Segurança (STI) 65 é logicamente conectado ao BNAS 29. O STI é posicionado para controlar o tráfego de entrada da rede ADSL. Em particular, o STI 65 intercepta os pacotes de dados gerados a partir do CPE 68 e direcionados à rede IP 22 através do BNAS 29.
[000119] O STI 65 opera pelo menos no nível de rede e captura os pacotes de dados saindo do BNAS 29. Se o STI opera somente no nível de rede ou até o nível de transporte somente, necessita capturar todos os pacotes de dados saindo do BNAS (e direcionados à rede IP), uma vez que não pode reconhecer as mensagens de aplicação levadas nos pacotes de dados, por exemplo, se esta é uma mensagem de requisição de acesso e em qual protocolo de nível de
Petição 870180053298, de 20/06/2018, pág. 48/66 / 48 aplicação a mensagem é levada. No caso em que o STI opera também no nível de aplicação, este pode reconhecer as mensagens de requisição de acesso e discriminar os diferentes protocolos de nível de aplicação. Por exemplo, se operando também no nível de aplicação, o STI pode ser programado para interceptar somente as mensagens de requisição de acesso e deixar passar as mensagens codificadas em outros protocolos.
[000120] Funções lógicas gerais do STI 65 são análogas àquelas do STI 10 descrito com referência à Figura 1. Em particular, a informação mínima que o STI tem que interceptar em um pacote de dados levando uma mensagem de requisição de acesso é a informação no nível de rede sobre o endereço do assinante, por exemplo, na Internet, o endereço IP alocado ao assinante.
[000121] Pelo menos parte da informação contida nos pacotes de dados capturados pelo STI 65 é passada para a Autoridade de Identidade (IA) que opera no nível de aplicação. A IA é responsável pelo gerenciamento da entidade dos assinantes acessando a PDN externa, isto é, rede IP 22. A IA recebe do STI pelo menos o endereço IP do assinante e a informação sobre o protocolo de nível de aplicação da mensagem de requisição de acesso. A última informação pode ser obtida recebendo o pacote de dados do STI (como um “envelope fechado” se o STI opera somente até o nível de rede/transporte) ou, se o STI opera também no nível de aplicação, recebendo informação específica tal como o tipo de protocolo.
[000122] As funções lógicas da IA 64 são substancialmente as mesmas daquelas descritas com referência à Figura 1. Em particular, a IA identifica o assinante (isto é, a estação do assinante, por exemplo, via conexão de cartão inteligente ou a partir do STI 65 e obtendo conhecimento da identidade do assinante, interrogando à AAA 26, que contém o mapeamento entre os endereços IP alocados e uma identidade (ou identidades) de assinante.
[000123] Preferivelmente, a IA armazena a informação relativa à identidade do assinante e ao serviço que requisita. A informação sobre o
Petição 870180053298, de 20/06/2018, pág. 49/66 / 48 serviço requisitado pode ser o endereço IP e/ou o URI do provedor de serviço e/ou do protocolo usado pelo serviço, no caso do provedor de serviço oferecer mais serviços usando diferentes protocolos (por exemplo, POP 3 para conta de e-mail e HTTP para navegação da Web). Na Figura 8, um exemplo de uma tabela com a informação armazenada na IA 64 é relatada. A tabela ilustrada provê um mapeamento para assinantes A, B e C, que desejam acessar um ou mais serviços caracterizados pelo provedor de serviço SP-1, SP-2, etc. No exemplo da Figura 8, os assinantes são identificados por seu ID de conexão, por exemplo um nome de usuário e senha (LOGIN-A, LOGIN-B, etc.). Preferivelmente, um pseudônimo PS é criado pela IA para cada assinante, por exemplo um PS correspondente a um ID de conexão do assinante é criado. Alternativamente, conforme relatado na Figura 8, mais pseudônimos podem ser gerados para um assinante, onde cada pseudônimo caracteriza um serviço específico requisitado pelo assinante. A criação de pseudônimos é preferida no sentido de evitar descrever dados sensíveis, tais como o CLI ou o ID de conexão.
[000124] Depois de ter verificado a identidade do assinante, por exemplo, mapeando o endereço IP com o ID de conexão associado ao assinante, a IA gera uma ficha de software de acordo com o protocolo de nível de aplicação da mensagem de requisição de acesso. A ficha é inserida na mensagem de requisição de acesso, por exemplo como um campo inserido em um cabeçalho de aplicação existente da mensagem, ou como um novo cabeçalho de aplicação adicionado na mensagem.
[000125] Dependendo de em qual nível o STI opera, ou a ficha pode ser inserida na mensagem pela IA, ou a IA pode requisitar ao STI para inserir a ficha na mensagem. A última opção supõe que o STI opera também no nível de aplicação. Em qualquer dos casos, o STI envia a mensagem de requisição de acesso modificada, isto é, contendo a ficha, ao servidor de aplicação 24, que recebe uma mensagem autenticada.
Petição 870180053298, de 20/06/2018, pág. 50/66 / 48 [000126] A ficha de autenticação inclui um identificador do assinante associado a uma identidade de assinante definida na rede de acesso fixa.
[000127] Preferivelmente, o identificador de assinante incluído na ficha é um pseudônimo associado a uma identidade de assinante por exemplo o CLI ou o ID de conexão. O uso de um pseudônimo protege a privacidade do assinante e evita a descrição de informação sensível, embora a presente invenção não exclua o uso na ficha de autenticação de uma identidade de assinante definida na PSTN ou na rede de acesso fixa. Alternativamente, o identificador pode ser um caracter/código de autorização designado pela operadora da PSTN a um assinante, na dependência, por exemplo, de seu crédito. Embora seja preferido que o identificador corresponda univocamente a uma identidade de assinante, o mesmo caracter/código de autorização pode ser designado a um grupo de assinante, por exemplo, agrupado por idade.
[000128] Opcionalmente, a IA 64 passa a ficha gerada, antes de transmitila ao STI, a um serviço de Infra-estrutura de Código Público (PKI) 63, que certifica a ficha, por exemplo, adicionando uma assinatura digital à ficha, por meio de criptografia assimétrica, que é conhecida de per si.
[000129] Embora mostrados como componentes externos separados do BNAS 29, o STI 65 e a IA 64 podem ser preferivelmente implementados dentro da BNAS, por exemplo, como módulos de software que são embutidos na lógica de controle do BNAS. Isto pode melhorar a segurança do STI contra ataques no nível da rede, uma vez que eliminaria a conexão física entre o BNAS e o STI.
[000130] Embora realizações da presente invenção sejam descritas com referência às Figuras 7 a 9 no contexto da tecnologia de linha de assinante digital (DSL) (e em particular tecnologia ADSL) será entendido que a presente invenção não está limitada a tecnologias xDSL. Realmente outras tecnologias de acesso e/ou configurações de rede, tais como, porém não limitadas a coaxial de fibra híbrida (HFC), conexões sem fio (por exemplo,
Petição 870180053298, de 20/06/2018, pág. 51/66 / 48
Wi-Fi® ou WiMAX), fibra doméstica (FTTH) e/ou Ethernet podem também ser usadas em outras realizações da presente invenção.
[000131] Figura 9 ilustra um diagrama de processamento de uma operação de acesso a um site da Web hospedado em um servidor de aplicação. Os componentes principais interagindo no fluxo de processo possuem as mesmas funções lógicas daqueles descritos com referência à Figura 7 e são indicados com o mesmo número de referência. Nesta realização, a estação do assinante requisita o acesso a um serviço “abc’” oferecido na rede IP pública usando o protocolo SOAP. A requisição HTTP poderia ser, por exemplo, uma HTTP POST, por exemplo, “POST /abc HTTP/1.T”. A estação do assinante, que nesta realização é um dispositivo periférico de usuário final 18 (por exemplo, um PC) conectado a um modem ADSL, autentica na infra-estrutura ADSL de uma maneira conhecida de per si, na etapa 91. A saber, a etapa 91 representa de uma maneira simplificada a interação entre o PC 18 (via uma modem DSL) e o BNAS 29, necessária para a estação de assinante obter acesso à rede externa. Dentro da fase de autenticação, a AAA 26 aloca um endereço IP à estação de assinante e armazena na memória a informação de mapeamento entre o endereço IP e uma identidade de assinante, pelo menos pela duração da sessão de dados. A estação de assinante é então autorizada a partir da rede de acesso ADSL a acessar serviços IP e um endereço IP é designado ao assinante.
[000132] Após a fase de autorização e autenticação dentro da rede de acesso da etapa 91, na etapa 92 a mensagem de requisição de acesso levada em um pacote de dados é enviada pelo BNAS à rede externa. A linha tracejada da etapa 92 representa o caminho lógico que a mensagem teria percorrido sem o mecanismo de autenticação de acordo com a presente invenção, isto é, a mensagem teria sido transmitida ao servidor de aplicação 24.
[000133] De acordo com a presente invenção, na etapa 92, o pacote de
Petição 870180053298, de 20/06/2018, pág. 52/66 / 48 dados abrangendo a mensagem de requisição de acesso é interceptado pelo STI 65, que está localizado entre o BNAS 29 e a rede pública. O STI extrai do pacote de dados interceptado o endereço IP do assinante, isto é, o endereço alocado à estação de assinante para a sessão, e preferivelmente o endereço de destino IP, isto é, o endereço do servidor de aplicação 24. O STI então envia a mensagem de aplicação (neste caso uma mensagem SOAP) e o endereço IP do assinante à IA 64 (etapa 93).
[000134] Se o STI opera a níveis mais baixos que o nível de aplicação, a mensagem é automaticamente redirecionada para a IA, por exemplo, redirecionando o(s) cabeçalho(s) de aplicação na direção da IA. Inversamente, se o STI opera no nível de aplicação, este reconhece o protocolo usado na mensagem de nível de aplicação, neste caso o protocolo SOAP sobre HTTP. Em qualquer caso, a IA obtém conhecimento do endereço IP do assinante e do protocolo de nível de aplicação com o qual a mensagem é conforme. A transmissão de informação entre o STI e a IA pode ocorrer, por exemplo, por meio de interfaces especificadas na Arquitetura Broker @ de Requisição de Objeto Comum (CORBA) tal como a Linguagem de Definição de Interface (IDL) ou em linguagens de Serviços da Web, tal como a Linguagem de Descrição de Serviço da Web (WSDL).
[000135] Na etapa 94, a IA 64 interroga a AAA 26 para determinar uma identidade do assinante na PSTN, citada identidade correspondendo ao endereço IP fonte capturado no pacote de dados. Na etapa 95, a AAA 26 responde à interrogação provendo a IA de uma identidade de assinante, representada neste caso pelo ID de Conexão, associado ao endereço IP.
[000136] Na próxima etapa (etapa 96), a IA gera uma ficha incluindo um identificador do assinante. A ficha, por exemplo, uma cadeia de caracteres, pode ser definida por exemplo, de acordo com a especificação de Segurança WS (indicada na Figura 9 como <WS>token). Preferivelmente, o identificador incluído na ficha é um pseudônimo criado pela IA e associado
Petição 870180053298, de 20/06/2018, pág. 53/66 / 48 ao ID de conexão. O identificador pode também ser associado ao provedor de serviço, como no exemplo ilustrado na Figura 8, tal como no caso em que mais pseudônimos são criados para o mesmo assinante, isto é, o mesmo ID de conexão, para acessar diferentes serviços dentro de uma sessão, como no caso do mecanismo de acesso de assinatura única (SSO). A IA não perde de vista o mapeamento entre o(s) pseudônimo(s) e a identidade de assinante definida na PSTN (por exemplo, o ID de conexão ou CLI), pelo menos pela duração da sessão.
[000137] Opcionalmente, a ficha é redirecionada ao serviço PKI 63 para afixar uma assinatura digital à ficha ou para criptografá-la de acordo com mecanismos de criptografia conhecidos (etapa 97). Na etapa 98, a PKI retorna a ficha certificada com uma assinatura digital e/ou assegurada por meio de criptografia. A ficha certificada/criptografada é indicada na Figura 9 por DS( <WS>-token).
[000138] Em seguida à etapa 95, (ou etapa 97 se o serviço PKI estiver incluído), a IA cria uma nova mensagem de requisição de acesso, indicada por “New-soap que inclui a ficha gerada (etapa 98). Na etapa 98, a nova mensagem de requisição de acesso (incluindo a ficha) é passada ao STI para transmissão. Por exemplo, a nova mensagem é a mensagem de requisição de acesso transmitida a partir da estação de assinante na qual a ficha tenha sido adicionada no envelope SOAP como um campo adicional conforme descrito na especificação de Segurança WS OASIS. O STI que copiou previamente e armazenou em sua memória o pacote de dados a partir do qual a informação tenha sido extraída, então transmite a mensagem de requisição de acesso recebida ao servidor de aplicação 24 (etapa 99).
[000139] Se uma assinatura digital foi afixada à ficha, o servidor de aplicação verifica a assinatura digital interrogando o serviço PKI (etapa 100). Por exemplo, a PKI verifica que o certificado da assinatura digital da ficha é válida.
Petição 870180053298, de 20/06/2018, pág. 54/66 / 48 [000140] Finalmente, o servidor de aplicação 24, que recebeu a autenticação da identidade do assinante por meio da ficha, provê ao assinante autenticado o serviço requisitado (etapa 101).
[000141] Deve ser notado que o mecanismo de autenticação descrito na Figura 9 é transparente ao usuário, que não necessita inserir credenciais para acessar o serviço. Em adição, o mecanismo de autenticação permite um acesso transparente a diversos serviços com um mecanismo SSO, o que geralmente pressupõe que existe um acordo entre provedores de serviço oferecendo os serviços (federação de identidade).
[000142] Nos anos recentes tornou-se mais e mais comum que um usuário seja um assinante de mais redes de telecomunicações e portanto, deseje ou necessite acessar serviços de aplicação de diferentes redes. Conforme descrito com referência às Figuras 2 e 8, diferentes pseudônimos podem ser criados para o mesmo assinante tendo acesso a diferentes serviços de aplicação que podem ser (mais não necessariamente) fornecidos por diferentes provedores de serviço. O requerente notou que um usuário pode ser identificado em uma aplicação de serviço (isto é, para um provedor de serviço) por um pseudônimo, que é o mesmo para as diferentes redes a partir das quais o usuário acessa o serviço. Figura 10 ilustra esquematicamente um cenário onde um usuário é um assinante de mais de uma rede de telecomunicação, a saber uma rede de acesso ADSL 121, uma rede de acesso sem fio (Wi-Fi®) 124, uma rede GPRS/GSM 128 e uma rede UMTS 126. O usuário pode enviar uma requisição para acessar um serviço de aplicação no servidor de aplicação 129, através da rede IP 120 a partir das redes 121, 124, 126 ou 128. Um endereço IP é ativado dentro da primeira rede na qual a requisição é liberada, e é associado a um identificador por um servidor AAA (não mostrado), sempre dentro da primeira rede. De acordo com uma realização preferida da invenção, um Injetor de Ficha de Segurança (STI) é logicamente conectado ao ponto de conexão de acesso ou ponto de acesso (por exemplo, BNAS,
Petição 870180053298, de 20/06/2018, pág. 55/66 / 48
GGSN), que atua como ponto de conexão para a rede IP, de cada primeira rede a partir da qual o assinante requisita o serviço de aplicação. Os STI 122, 123, 125 e 127 interceptam mensagens de requisição de acesso originadas das redes 121, 124, 126 e 127, respectivamente. Embora não mostrado na figura, cada STI é logicamente conectado a uma Autoridade de Identidade (IA) que é responsável pelo gerenciamento da identidade do assinante acessando o serviço de aplicação através da rede IP. A funcionalidade e operações lógicas do STI e da IA são descritas em mais detalhe com referência às realizações prévias. Em particular, a IA e cada primeira rede obtém conhecimento da identidade do assinante a partir do endereço IP capturado e associa um pseudônimo ao endereço IP, que não só identifica o assinante (por sua associação a uma identidade de assinante dentro da primeira rede), mas relaciona ao serviço de aplicação requisitado. No sentido de ser capaz de relacionar o serviço requisitado ao pseudônimo, a IA (ou o STI se este opera no nível de aplicação) necessita extrair da mensagem de requisição de acesso o URI do serviço requisitado. Obtendo o conhecimento do URI, o identificador do assinante pode ser associado ao pseudônimo relacionado ao serviço e então ser inserido na mensagem de requisição de acesso. O pseudônimo relacionado ao serviço pode ser criado pelo provedor de serviço executando o serviço requisitado, e então comunicado às IA. Várias soluções são possíveis para executar tal comunicação. Esta poderia ser de um modo off-line, através de algumas ferramentas de provisionamento providas pelas IA e usadas pelo provedor de serviço, ou no tempo de execução, por meio de protocolos, tais como aqueles especificados pelo consórcio Aliança Liberty para suportar federação de identidade.
[000143] Deve ser notado que também nesta realização a identidade de assinante é garantida pela primeira rede: a partir da qual um usuário requisita o serviço.
[000144] Um cenário possível de acesso por multi-rede pode ser aquele de
Petição 870180053298, de 20/06/2018, pág. 56/66 / 48 um usuário que é um assinante de diversas redes, por exemplo, uma rede GPRS, UMTS e uma rede de acesso fixo tal como xDSL através de linhas telefônicas da PSTN, que são gerenciadas por uma operadora de multiplataforma.
[000145] O requerente observou que alguns serviços requerem autenticação mútua entre o cliente (isto é, a estação de assinante) e o servidor. Em outras palavras, ao utilizar alguns serviços através de uma rede externa tal como Internet, o usuário pode necessitar ou desejar saber se está realmente se comunicando com o servidor desejado ou correto. Se um computador remoto é capaz de imitar o comportamento do servidor, então o usuário pode ser logrado ou trapaceado ao pensar que está e comunicação com o servidor correto. Por exemplo, informação sobre instituições financeiras, seus usuário e transações financeiras têm sido tradicionalmente consideradas muito sensíveis a segurança e credibilidade. Hoje em dia, criptografia de par de código assimétrico é freqüentemente usada, por exemplo, nos serviços bancários via Internet para garantir segurança e confidencialidade.
[000146] Figura 11 é um diagrama de processo simplificado que ilustra um acesso a um serviço hospedado em um servidor de aplicação através de uma PDN em um contexto de autenticação mútua, de acordo com uma realização preferida da invenção. Na etapa 113, a estação de assinante 110, que pode ser uma estação móvel ou CPE, requisita um serviço hospedado no servidor de aplicação 112. Neste exemplo, a mensagem é uma mensagem de requisição de acesso HTTP do tipo POST. Sempre na etapa 113, e de acordo com um método da presente invenção (descrito em mais detalhe nas realizações prévias), a citada mensagem é interceptada por um STI 111 e uma ficha, isto é, Ficha-c é criada e associada à mensagem. O STI então envia a mensagem com a ficha associada ao servidor de aplicação (etapa 114). Após ter recebido a mensagem (e tendo opcionalmente verificado a validade de autenticação) o servidor 112 cria uma ficha de resposta, Token-s que é colocada na resposta
Petição 870180053298, de 20/06/2018, pág. 57/66 / 48 positiva “Bem-vindo” para a mensagem POST recebida. A Token-s pode ser uma cadeia de caracteres implementada no software que executa o serviço de aplicação (por exemplo, Servlet Java ou Páginas de Servidor Ativo Microsoft), por exemplo de acordo com um padrão tal como uma asserção SAML. Alternativamente, a Token-s é gerada por uma entidade lógica (não mostrada na figura) logicamente conectada ao servidor, preferivelmente nas premissas de provedor de serviço. A entidade lógica pode ser uma barreira de proteção localizada diante do servidor de aplicação, [000147] A mensagem de resposta incluindo a Token-s e transmitida pelo servidor de aplicação 112 à estação de assinante 110 é interceptada pelo STI 111, que extrai a Token-s da mensagem de resposta e verifica sua validade. A validade pode ser verificada por meio de uma assinatura digital ou por um código simétrico secreto, por exemplo, compartilhado entre a operadora de rede (supondo que o STI esteja nas premissas da operadora) e o provedor de serviço. Se a validade da Token-s é positivamente verificada, o STI transmite a mensagem de resposta positiva interceptada “Bem-vindo” à estação de assinante (etapa 116) ou cria uma nova mensagem de resposta positiva que é transmitida à estação de assinante 110. caso contrário, o STI interrompe a comunicação e envia uma mensagem de erro à estação de assinante (não mostrada na figura).
[000148] Na presente realização, é suposto que o STI opera no nível de aplicação e portanto, pode não só interceptar a mensagem de resposta transmitida do servidor de aplicação, como também extrair a Token-s. Deve ser entendido que, no caso do STI operar até o nível de transporte, o STI 111 intercepta a mensagem de resposta e então transmite-a à IA (não mostrado na Figura 11), que extrai a Token-s do nível de aplicação e verifica sua validade.
[000149] Preferivelmente, no sentido de evitar interceptação ou roubo da Token-s por uma parte não autorizada, a citada ficha pode ser protegida por criptografia ou ser associada a um tempo de vida.
Petição 870180053298, de 20/06/2018, pág. 58/66 / 48 [000150] E importante notar que também o mecanismo de autenticação do servidor tem a vantagem de ser transparente ao usuário final.

Claims (37)

  1. REIVINDICAÇÕES
    1. Método para autenticar um assinante de uma primeira rede para acessar um serviço de aplicação através de uma segunda rede, onde a segunda rede é uma rede de dados por pacotes (PDN) e o acesso aos serviços de aplicação é na forma de mensagens de requisição de acesso incluídas em um pacote de dados, citado pacote de dados incluindo um endereço na citada segunda rede alocada a um endereço do assinante e a citada mensagem de requisição de acesso expressa com uma sintaxe que atende a um protocolo de nível de aplicação, caracterizado pelo fato de compreender as etapas de:
    a) interceptar uma mensagem de requisição de acesso para a segunda rede;
    b) reconhecer o protocolo de nível de aplicação;
    c) prover o mapeamento entre o endereço do assinante e um primeiro identificador do assinante na primeira rede;
    d) gerar uma primeira ficha de autenticação incluindo um segundo identificador do assinante;
    e) associar a primeira ficha de autenticação à mensagem de requisição de acesso, e
    f) transmitir a mensagem de requisição de acesso com a citada primeira ficha de autenticação associada, à segunda rede.
  2. 2. Método de acordo com a reivindicação 1, caracterizado pelo fato de que a segunda rede é uma rede IP e o endereço do assinante é o endereço IP.
  3. 3. Método de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que a primeira rede é uma rede móvel.
  4. 4. Método de acordo com a reivindicação 3, caracterizado pelo fato de que a rede móvel é uma rede celular comutada por pacotes.
  5. 5. Método de acordo com a reivindicação 4, caracterizado pelo fato de que a rede celular comutada por pacotes é uma rede GPRS.
    Petição 870180053298, de 20/06/2018, pág. 60/66
  6. 6. Método de acordo com a reivindicação 4, caracterizado pelo fato de que a rede celular comutada por pacotes é uma rede EDGE ou UMTS.
  7. 7. Método de acordo com a reivindicação 1, caracterizado pelo fato de que o primeiro e o segundo identificadores de assinantes são diferentes um do outro.
  8. 8. Método de acordo com a reivindicação 7, caracterizado pelo fato de que a primeira rede é uma rede GSM e o identificador do primeiro assinante é uma identidade baseada em SIM.
  9. 9. Método de acordo com a reivindicação 8, caracterizado pelo fato de que a identidade baseada em SIM é a IMSI associada ao assinante, na rede GSM.
  10. 10. Método de acordo com a reivindicação 7, caracterizado pelo fato de que o identificador do segundo assinante é um pseudônimo associado ao identificador do primeiro assinante.
  11. 11. Método de acordo com qualquer uma das reivindicações 1 a 10, caracterizado pelo fato de que a etapa e) compreende incluir a primeira ficha de autenticação na mensagem de requisição de acesso.
  12. 12. Método de acordo com qualquer uma das reivindicações 1 a 11, caracterizado pelo fato de incluir, após a etapa d) a etapa de criptografar a primeira ficha de autenticação com uma assinatura digital.
  13. 13. Método de acordo com qualquer uma das reivindicações 1 a 12, caracterizado pelo fato de que a citada primeira ficha de autenticação é expressa com uma sintaxe que é conforme ao protocolo de nível de aplicação da mensagem de requisição de acesso.
  14. 14. Método de acordo com qualquer uma das reivindicações 1 a 13, caracterizado pelo fato de que o protocolo de nível de aplicação é selecionado do grupo de SIP, HTTP e SOAP sobre HTTP.
  15. 15. Método de acordo com a reivindicação 1, caracterizado pelo fato de que o protocolo de nível de aplicação é SIP ou HTTP e a citada
    Petição 870180053298, de 20/06/2018, pág. 61/66 primeira ficha de autenticação é especificada de acordo com o padrão SAML.
  16. 16. Método de acordo com a reivindicação 1, caracterizado pelo fato de que a primeira rede é uma rede de acesso fixa.
  17. 17. Método de acordo com a reivindicação 16, caracterizado pelo fato de que a rede de acesso fixa usa tecnologia de acesso de Linha de Assinante Digital (xDSL).
  18. 18. Método de acordo com a reivindicação 16, caracterizado pelo fato de que o identificador do primeiro assinante é um ID de conexão.
  19. 19. Método de acordo com a reivindicação 1, caracterizado pelo fato de compreender adicionalmente, após a etapa f), as etapas de:
    g) receber, na aplicação de serviço através da citada segunda rede, a citada requisição de acesso com a citada primeira ficha de autenticação;
    h) gerar uma primeira mensagem de resposta para a citada mensagem de requisição de acesso recebida;
    i) gerar uma segunda ficha de autenticação e incluir a citada segunda ficha de autenticação na citada primeira mensagem de resposta;
    j) interceptar a citada primeira mensagem de resposta incluindo a citada segunda ficha de autenticação;
    k) extrair a citada segunda ficha de autenticação da citada primeira mensagem de resposta, e
    l) verificar a citada segunda ficha de autenticação e, se a verificação é positiva, transmitir uma segunda mensagem de resposta à primeira rede.
  20. 20. Método de acordo com a reivindicação 19, caracterizado pelo fato de compreender, após a etapa g), adicionalmente a etapa de verificar a citada primeira ficha de autenticação.
  21. 21. Método de acordo com a reivindicação 1, caracterizado pelo fato de compreender adicionalmente a etapa de prover um mapeamento
    Petição 870180053298, de 20/06/2018, pág. 62/66 entre a primeira ficha de autenticação e o serviço de aplicação requisitado.
  22. 22. Método de acordo com a reivindicação 21, caracterizado pelo fato de que o mapeamento entre a primeira ficha de autenticação e o serviço de aplicação requisitado compreende extrair a URI do serviço requisitado, da mensagem de requisição de acesso.
  23. 23. Método de acordo com a reivindicação 22, caracterizado pelo fato de que o identificador do segundo assinante é um pseudônimo associado ao identificador do primeiro assinante e ao serviço de aplicação requisitado.
  24. 24. Sistema para autenticar um assinante de uma primeira rede para acessar serviços de aplicação através de uma segunda rede, onde a segunda rede é uma rede de dados por pacotes (PDN), caracterizado pelo fato de compreender:
    uma estação de assinante (2, 68) acoplada à primeira rede e capaz de gerar mensagens de requisição de acesso incluídas em pacotes de dados, citadas mensagens de requisição de acesso sendo expressas com uma sintaxe conforme a um protocolo de nível de aplicação;
    um servidor de alocação (7, 26) capaz de alocar um endereço na citada segunda rede a um endereço do assinante e prover um mapeamento entre o endereço do assinante e um identificador do primeiro assinante, na primeira rede;
    um ponto de conexão (6, 29) capaz de executar as seguintes funções: receber as mensagens de requisição de acesso da estação de assinante (2), para interfacear a primeira rede com a segunda rede e para designar o endereço do assinante à estação de assinante;
    uma primeira entidade lógica (10, 65) conectada ao ponto de conexão (6, 29) e capaz de interceptar os pacotes de dados gerados a partir da estação de assinante (2, 18) e direcionados à segunda rede através do ponto de conexão (6, 29) e para capturar no pacote de dados pelo menos o endereço do
    Petição 870180053298, de 20/06/2018, pág. 63/66 assinante, e uma segunda entidade lógica (9, 64) conectada à primeira entidade lógica (10, 65) e capaz de executar as seguintes funções:
    receber o endereço do assinante e a mensagem de requisição de acesso da primeira entidade lógica, reconhecer o protocolo de nível de aplicação da mensagem de requisição de acesso, requisitar o primeiro identificador de assinante, ao servidor de alocação, e gerar uma primeira ficha de autenticação de acordo com o protocolo de nível de aplicação, citada ficha incluindo um segundo identificador de assinante, onde a primeira entidade lógica ou a segunda entidade lógica é capaz de associar a citada primeira ficha de autenticação à mensagem de requisição de acesso.
  25. 25. Sistema de acordo com a reivindicação 24, caracterizado pelo fato de que o servidor de alocação (7, 26) e o ponto de conexão (6, 29) estão incluídos na primeira rede.
  26. 26. Sistema de acordo com as reivindicações 24, caracterizado pelo fato de que a primeira entidade lógica (10, 65) e a segunda entidade lógica (9, 64) estão incluídas na primeira rede.
  27. 27. Sistema de acordo com uma das reivindicações 24, caracterizado pelo fato de que a primeira rede é uma rede móvel e a estação de assinante (2) é uma estação móvel acoplada à primeira rede via um enlace sem fio.
  28. 28. Sistema de acordo com a reivindicação 27, caracterizado pelo fato de que a primeira rede é uma rede celular comutada por pacote.
  29. 29. Sistema de acordo com a reivindicação 27 ou 28, caracterizado pelo fato de que o ponto de conexão (6) é um GGSN.
  30. 30. Sistema de acordo com a reivindicação 24, caracterizado
    Petição 870180053298, de 20/06/2018, pág. 64/66 pelo fato de que o servidor de alocação (7, 26) é um servidor de Conta de Autorização de Autenticação (AAA).
  31. 31. Sistema de acordo com a reivindicação 24, caracterizado pelo fato de que a segunda rede é uma rede IP (12, 22).
  32. 32. Sistema de acordo com a reivindicação 24, caracterizado pelo fato de incluir adicionalmente uma entidade lógica de certificação (8, 63) logicamente conectada à segunda entidade lógica (9, 64) e capaz de criptografar a primeira ficha de autenticação.
  33. 33. Sistema de acordo com a reivindicação 24, caracterizado pelo fato de que a primeira entidade lógica (10, 65) é uma barreira de proteção de nível de aplicação.
  34. 34. Sistema de acordo com a reivindicação 24, caracterizado pelo fato de que a primeira rede é uma rede de acesso fixa e a estação de assinante é um equipamento de premissas de usuário (68) acoplado à primeira rede via uma rede com fio (67).
  35. 35. Sistema de acordo com a reivindicação 34, caracterizado pelo fato de que o primeiro identificador de assinante é um ID de conexão.
  36. 36. Sistema de acordo com a reivindicação 24, caracterizado pelo fato de que a primeira entidade lógica (10, 65) é também capaz de interceptar mensagens de resposta transmitidas através da segunda rede e direcionadas à citada estação de assinante (2, 68) através do ponto de conexão (6, 29).
  37. 37. Sistema de acordo com a reivindicação 36, caracterizado pelo fato de que as citadas mensagens de resposta incluem uma segunda ficha de autenticação.
BRPI0517521-6A 2004-10-26 2005-09-30 Método e sistema para autenticar um assinante de uma primeira rede para acessar um serviço de aplicação através de uma segunda rede BRPI0517521B1 (pt)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EPPCT/EP2004/012052 2004-10-26
EP2004012052 2004-10-26
PCT/EP2005/010590 WO2006045402A1 (en) 2004-10-26 2005-09-30 Method and system for transparently authenticating a mobile user to access web services

Publications (2)

Publication Number Publication Date
BRPI0517521A BRPI0517521A (pt) 2008-10-14
BRPI0517521B1 true BRPI0517521B1 (pt) 2019-04-09

Family

ID=34959133

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI0517521-6A BRPI0517521B1 (pt) 2004-10-26 2005-09-30 Método e sistema para autenticar um assinante de uma primeira rede para acessar um serviço de aplicação através de uma segunda rede

Country Status (6)

Country Link
US (1) US7954141B2 (pt)
JP (1) JP4782139B2 (pt)
CN (1) CN101069402B (pt)
AR (1) AR053529A1 (pt)
BR (1) BRPI0517521B1 (pt)
WO (1) WO2006045402A1 (pt)

Families Citing this family (132)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8479189B2 (en) 2000-11-17 2013-07-02 Hewlett-Packard Development Company, L.P. Pattern detection preprocessor in an electronic device update generation system
US7409685B2 (en) 2002-04-12 2008-08-05 Hewlett-Packard Development Company, L.P. Initialization and update of software and/or firmware in electronic devices
US8244837B2 (en) * 2001-11-05 2012-08-14 Accenture Global Services Limited Central administration of one or more resources
US8555273B1 (en) 2003-09-17 2013-10-08 Palm. Inc. Network for updating electronic devices
US7904895B1 (en) 2004-04-21 2011-03-08 Hewlett-Packard Develpment Company, L.P. Firmware update in electronic devices employing update agent in a flash memory card
US8526940B1 (en) 2004-08-17 2013-09-03 Palm, Inc. Centralized rules repository for smart phone customer care
US20070245411A1 (en) * 2005-09-15 2007-10-18 Gregory Newton Methods, systems and computer program products for single sign on authentication
US8139521B2 (en) * 2005-10-28 2012-03-20 Interdigital Technology Corporation Wireless nodes with active authentication and associated methods
US7725928B2 (en) * 2005-12-02 2010-05-25 Palo Alto Research Center Incorporated System and method for establishing temporary and permanent credentials for secure online commerce
US8270947B2 (en) * 2005-12-19 2012-09-18 Motorola Solutions, Inc. Method and apparatus for providing a supplicant access to a requested service
US20070143470A1 (en) * 2005-12-20 2007-06-21 Nortel Networks Limited Facilitating integrated web and telecommunication services with collaborating web and telecommunication clients
WO2007111471A1 (en) * 2006-03-29 2007-10-04 Ktfreetel Co., Ltd. Digital device and method for providing additional service by using the same
US8745227B2 (en) * 2006-06-07 2014-06-03 Apple Inc. Distributed secure content delivery
EP2025095A2 (en) 2006-06-08 2009-02-18 Hewlett-Packard Development Company, L.P. Device management in a network
US8346265B2 (en) 2006-06-20 2013-01-01 Alcatel Lucent Secure communication network user mobility apparatus and methods
EP2039050B1 (en) 2006-07-10 2019-02-20 Telefonaktiebolaget LM Ericsson (publ) Method and arrangement for authentication procedures in a communication network
EP2047420A4 (en) 2006-07-27 2009-11-18 Hewlett Packard Development Co USER EXPERIENCE AND DEPENDENCE MANAGEMENT IN A MOBILE DEVICE
US7881297B2 (en) * 2006-09-01 2011-02-01 Avaya Inc. Providing communications including an extended protocol header
US20080066169A1 (en) * 2006-09-08 2008-03-13 Microsoft Corporation Fact Qualifiers in Security Scenarios
US8060931B2 (en) 2006-09-08 2011-11-15 Microsoft Corporation Security authorization queries
US8095969B2 (en) 2006-09-08 2012-01-10 Microsoft Corporation Security assertion revocation
US20080066158A1 (en) * 2006-09-08 2008-03-13 Microsoft Corporation Authorization Decisions with Principal Attributes
US8201215B2 (en) 2006-09-08 2012-06-12 Microsoft Corporation Controlling the delegation of rights
US20080065899A1 (en) * 2006-09-08 2008-03-13 Microsoft Corporation Variable Expressions in Security Assertions
US7814534B2 (en) * 2006-09-08 2010-10-12 Microsoft Corporation Auditing authorization decisions
US20080066147A1 (en) * 2006-09-11 2008-03-13 Microsoft Corporation Composable Security Policies
US8938783B2 (en) * 2006-09-11 2015-01-20 Microsoft Corporation Security language expressions for logic resolution
US8656503B2 (en) 2006-09-11 2014-02-18 Microsoft Corporation Security language translations with logic resolution
US8244845B2 (en) * 2006-11-29 2012-08-14 Hewlett-Packard Development Company, L.P. IP based notification of device management operations in a network
US20080162712A1 (en) * 2006-12-27 2008-07-03 Motorola, Inc. Method and apparatus to facilitate sharing streaming content via an identity provider
US20100088755A1 (en) * 2006-12-29 2010-04-08 Telefonaktiebolaget L M Ericsson (Publ) Access management for devices in communication networks
EP1959629B1 (en) 2007-02-13 2016-04-13 Vodafone GmbH Method for authenticating a user for access to server based applications from mobile device, gateway and identity management unit
US8331989B2 (en) 2007-06-15 2012-12-11 Intel Corporation Field programming of a mobile station with subscriber identification and related information
FI121646B (fi) * 2007-08-08 2011-02-15 Teliasonera Finland Oyj Menetelmä ja järjestelmä käyttäjäidentiteetin hallintaan
US20090064291A1 (en) * 2007-08-28 2009-03-05 Mark Frederick Wahl System and method for relaying authentication at network attachment
US7945246B2 (en) * 2007-10-26 2011-05-17 Sony Ericsson Mobile Communications Ab System and method for establishing authenticated network communications in electronic equipment
US8839386B2 (en) * 2007-12-03 2014-09-16 At&T Intellectual Property I, L.P. Method and apparatus for providing authentication
WO2009087006A1 (en) * 2008-01-09 2009-07-16 Nokia Siemens Networks Oy Mechanism for authentication and authorization for network and service access
US8107921B2 (en) * 2008-01-11 2012-01-31 Seven Networks, Inc. Mobile virtual network operator
WO2009092105A2 (en) * 2008-01-18 2009-07-23 Tekelec Systems, methods and computer readable media for application-level authentication of messages in a telecommunications network
CN101547383B (zh) * 2008-03-26 2013-06-05 华为技术有限公司 一种接入认证方法及接入认证***以及相关设备
WO2009122219A1 (en) * 2008-04-02 2009-10-08 Vodafone Group Plc Telecommunications network
JP5051656B2 (ja) * 2008-06-05 2012-10-17 日本電気株式会社 通信制御システムおよび通信制御方法
US8751788B2 (en) * 2008-06-10 2014-06-10 Paymetric, Inc. Payment encryption accelerator
RU2012101303A (ru) 2008-06-17 2013-07-27 Диджигейдж Лтд. Система для изменения виртуальных видов
WO2010000298A1 (en) * 2008-06-30 2010-01-07 Nokia Siemens Networks Oy Apparatus, method and program for integrated authentication
US8910257B2 (en) * 2008-07-07 2014-12-09 Microsoft Corporation Representing security identities using claims
KR101001555B1 (ko) * 2008-09-23 2010-12-17 한국전자통신연구원 네트워크 ｉｄ 기반 연합 및 싱글사인온 인증 방법
US8171057B2 (en) * 2008-10-23 2012-05-01 Microsoft Corporation Modeling party identities in computer storage systems
US20100192183A1 (en) * 2009-01-29 2010-07-29 At&T Intellectual Property I, L.P. Mobile Device Access to Multimedia Content Recorded at Customer Premises
JP4715937B2 (ja) * 2009-03-06 2011-07-06 ブラザー工業株式会社 端末装置とコンピュータプログラム
US8370509B2 (en) 2009-04-09 2013-02-05 Alcatel Lucent Identity management services provided by network operator
CN102460453B (zh) 2009-04-13 2014-12-24 黑莓有限公司 用于确定sip消息的可信度的***和方法
WO2010127380A1 (en) * 2009-05-08 2010-11-11 Hewlett-Packard Development Company, L.P. Access control of distributed computing resources system and method
EP2259551A1 (en) 2009-06-05 2010-12-08 Software AG Gateway server system comprising a gateway server for making SOAP/XML-based web services accessible to RPC clients
CN101945375A (zh) * 2009-07-07 2011-01-12 中兴通讯股份有限公司 一种选择应用前端的方法及用户数据仓储
DE102009040477A1 (de) * 2009-09-08 2011-03-10 Deutsche Telekom Ag Authentifizierung im Mobilfunknetz durch Authentifizierungszelle
US8832815B2 (en) * 2009-09-09 2014-09-09 T-Mobile Usa, Inc. Accessory based data distribution
EP2306682A1 (en) * 2009-09-30 2011-04-06 British Telecommunications public limited company Method of configuring a device to self-authenticate
GB2474504B (en) 2009-10-19 2015-12-02 Ubiquisys Ltd Wireless access point
CN101692674B (zh) 2009-10-30 2012-10-17 杭州华三通信技术有限公司 双栈接入的方法和设备
US9119076B1 (en) 2009-12-11 2015-08-25 Emc Corporation System and method for authentication using a mobile communication device
US8860581B2 (en) * 2010-01-19 2014-10-14 T-Mobile Usa, Inc. Element mapping to control illumination of a device shell
US9003489B2 (en) * 2010-02-04 2015-04-07 Cisco Technology, Inc. System and method for providing virtual user groups in a network environment
US8280351B1 (en) 2010-02-04 2012-10-02 Cellco Partnership Automatic device authentication and account identification without user input when application is started on mobile station
US9107072B2 (en) * 2010-02-12 2015-08-11 Alexander Hoi WONG Seamless mobile subscriber identification
US8868758B2 (en) * 2010-05-04 2014-10-21 Microsoft Corporation Provider connection framework
US8973125B2 (en) * 2010-05-28 2015-03-03 Alcatel Lucent Application layer authentication in packet networks
US8997196B2 (en) * 2010-06-14 2015-03-31 Microsoft Corporation Flexible end-point compliance and strong authentication for distributed hybrid enterprises
US9560036B2 (en) * 2010-07-08 2017-01-31 International Business Machines Corporation Cross-protocol federated single sign-on (F-SSO) for cloud enablement
US9560035B2 (en) 2010-08-04 2017-01-31 At&T Mobility Ii Llc Systems, devices, methods and computer program products for establishing network connections between service providers and applications that run natively on devices
US9319880B2 (en) 2010-09-15 2016-04-19 Intel Corporation Reformatting data to decrease bandwidth between a video encoder and a buffer
EP2630749B1 (en) 2010-10-22 2019-01-30 Hewlett-Packard Enterprise Development LP Distributed network instrumentation system
EP2466522A1 (en) * 2010-11-30 2012-06-20 Gemalto SA Method for providing a user with an authentificated remote access to a remote secure device
US9198038B2 (en) * 2011-06-13 2015-11-24 Qualcomm Incorporated Apparatus and methods of identity management in a multi-network system
US9270453B2 (en) 2011-06-30 2016-02-23 Verizon Patent And Licensing Inc. Local security key generation
US8943318B2 (en) 2012-05-11 2015-01-27 Verizon Patent And Licensing Inc. Secure messaging by key generation information transfer
US8990554B2 (en) * 2011-06-30 2015-03-24 Verizon Patent And Licensing Inc. Network optimization for secure connection establishment or secure messaging
US9154527B2 (en) 2011-06-30 2015-10-06 Verizon Patent And Licensing Inc. Security key creation
US20130007867A1 (en) * 2011-06-30 2013-01-03 Cisco Technology, Inc. Network Identity for Software-as-a-Service Authentication
US8918850B2 (en) 2011-08-01 2014-12-23 Google Inc. Share cookie on native platform in mobile device without having to ask for the user's login information
CN102917354B (zh) * 2011-08-03 2018-04-13 中兴通讯股份有限公司 一种接入方法、***及移动智能接入点
US9191381B1 (en) * 2011-08-25 2015-11-17 Symantec Corporation Strong authentication via a federated identity protocol
JP5934364B2 (ja) 2011-09-09 2016-06-15 インテル コーポレイション Ｓｏａｐ−ｘｍｌ技術を使用したｗｉ−ｆｉホットスポットのための安全なオンラインサインアップ及び提供のためのモバイルデバイス及び方法
SG10201601550XA (en) * 2011-09-26 2016-03-30 Elta Systems Ltd A Mobile Communication System Implementing Integration Of Multiple Logins Of Mobile Device Applications
US9100324B2 (en) 2011-10-18 2015-08-04 Secure Crossing Research & Development, Inc. Network protocol analyzer apparatus and method
US8949938B2 (en) 2011-10-27 2015-02-03 Cisco Technology, Inc. Mechanisms to use network session identifiers for software-as-a-service authentication
EP2795946B1 (en) * 2011-12-23 2015-10-14 Telefonaktiebolaget L M Ericsson (PUBL) Methods and apparatuses for determining a user identity token for identifying user of a communication network
US8959591B2 (en) * 2012-01-06 2015-02-17 Elastic Path Software, Inc. Follow location handler and selector functionality in a stateless microkernel web server architecture
EP2815623B1 (en) * 2012-02-14 2018-08-29 Nokia Technologies Oy Device to device security using naf key
US9054892B2 (en) * 2012-02-21 2015-06-09 Ecolink Intelligent Technology, Inc. Method and apparatus for registering remote network devices with a control device
ZA201301790B (en) * 2012-03-08 2015-09-30 Oltio (Pty) Ltd A method of authenticating a device and encrypting data transmitted between the device and a server
EP2834964B1 (en) * 2012-04-03 2017-06-07 Telefonaktiebolaget LM Ericsson (publ) Method and apparatus for providing a subscriber identity
US9152781B2 (en) 2012-08-09 2015-10-06 Cisco Technology, Inc. Secure mobile client with assertions for access to service provider applications
US9185093B2 (en) * 2012-10-16 2015-11-10 Mcafee, Inc. System and method for correlating network information with subscriber information in a mobile network environment
US9338657B2 (en) 2012-10-16 2016-05-10 Mcafee, Inc. System and method for correlating security events with subscriber information in a mobile network environment
WO2014060008A1 (en) 2012-10-19 2014-04-24 Unify Gmbh & Co. Kg Method and system for creating a virtual sip user agent by use of a webrtc enabled web browser
US20150223059A1 (en) * 2013-03-01 2015-08-06 Intel Corporation Techniques for establishing access to a local wireless network
JP6201207B2 (ja) * 2013-05-27 2017-09-27 Kddi株式会社 通信端末装置、プログラムおよび通信方法
CN103414745A (zh) * 2013-07-05 2013-11-27 惠州Tcl移动通信有限公司 一种移动终端跨浏览器登陆的方法和装置
US9621735B2 (en) 2014-06-25 2017-04-11 Textnow, Inc. Mobile electronic communications combining voice-over-IP and mobile network services
EP2961208A1 (en) * 2014-06-27 2015-12-30 Gemalto SA Method for accessing a service and corresponding application server, device and system
CN104199843B (zh) * 2014-08-07 2017-09-26 蔡剑 一种基于社会网络交互数据的服务排序及推荐方法与***
CN104506510B (zh) * 2014-12-15 2017-02-08 百度在线网络技术（北京）有限公司 用于设备认证的方法、装置及认证服务***
US9680646B2 (en) * 2015-02-05 2017-06-13 Apple Inc. Relay service for communication between controllers and accessories
US10505850B2 (en) * 2015-02-24 2019-12-10 Qualcomm Incorporated Efficient policy enforcement using network tokens for services—user-plane approach
US9749310B2 (en) * 2015-03-27 2017-08-29 Intel Corporation Technologies for authentication and single-sign-on using device security assertions
US10341239B2 (en) 2015-05-21 2019-07-02 Qualcomm Incorporated Efficient policy enforcement for downlink traffic using network access tokens—control-plane approach
US10216800B2 (en) * 2015-06-18 2019-02-26 Rocket Apps, Inc. Self expiring social media
US10225241B2 (en) * 2016-02-12 2019-03-05 Jpu.Io Ltd Mobile security offloader
EP3435615B1 (en) * 2016-03-28 2021-04-14 Huawei Technologies Co., Ltd. Network service implementation method, service controller, and communication system
KR20180126494A (ko) * 2016-04-01 2018-11-27 인텔 코포레이션 대화를 통한 디바이스 식별 기법
US9769668B1 (en) 2016-08-01 2017-09-19 At&T Intellectual Property I, L.P. System and method for common authentication across subscribed services
US10158684B2 (en) * 2016-09-26 2018-12-18 Cisco Technology, Inc. Challenge-response proximity verification of user devices based on token-to-symbol mapping definitions
CN108024248B (zh) * 2016-10-31 2022-11-08 中兴通讯股份有限公司 一种物联网平台的鉴权方法和装置
CN106790082B (zh) * 2016-12-22 2019-10-01 北京启明星辰信息安全技术有限公司 一种云应用访问控制方法及***
US10492056B2 (en) * 2017-06-15 2019-11-26 T-Mobile Usa, Inc. Enhanced mobile subscriber privacy in telecommunications networks
US10750028B2 (en) 2017-06-29 2020-08-18 Textnow, Inc. Mobile communications with quality of service
US10637845B2 (en) 2017-07-21 2020-04-28 International Business Machines Corporation Privacy-aware ID gateway
US10277586B1 (en) * 2018-10-29 2019-04-30 Syniverse Technologies, Llc Mobile authentication with URL-redirect
US11421411B2 (en) 2018-12-19 2022-08-23 Bemis Manufacturing Company Washing toilet seat
CN109756508B (zh) * 2019-01-22 2022-11-08 深圳壹账通智能科技有限公司 基于多协议接入区块链网络的消息代理方法及相关设备
US20200304508A1 (en) * 2019-03-18 2020-09-24 Samsung Electronics Co., Ltd. Method and device for providing authentication in network-based media processing (nbmp) system
CN113647074A (zh) * 2019-03-29 2021-11-12 三星电子株式会社 用于边缘计算服务的方法及其电子装置
EP3836504A1 (en) * 2019-12-12 2021-06-16 Noscendo GmbH Providing and obtaining one or more data sets via a digital communication network
GB2594930A (en) * 2020-05-05 2021-11-17 Truphone Ltd Authentication of devices to third party services
WO2022044142A1 (ja) * 2020-08-26 2022-03-03 日本電信電話株式会社 公開鍵認証装置及び公開鍵認証方法
CN113206836A (zh) * 2021-04-12 2021-08-03 河海大学 一种工业互联网中api网关实现协议转换的方法
US11877218B1 (en) 2021-07-13 2024-01-16 T-Mobile Usa, Inc. Multi-factor authentication using biometric and subscriber data systems and methods
CN115883119B (zh) * 2021-09-29 2024-05-24 富联精密电子(天津)有限公司 服务验证方法、电子装置及存储介质
CN114090122B (zh) * 2021-11-12 2023-05-23 广州通则康威智能科技有限公司 小程序配置cpe的方法、装置、计算机设备及存储介质
CN114760138B (zh) * 2022-04-20 2024-02-13 深圳市昊洋智能有限公司 基于云架构下的视频会议***安全方法及装置

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2348778A (en) * 1999-04-08 2000-10-11 Ericsson Telefon Ab L M Authentication in mobile internet access
DE69939494D1 (de) * 1999-07-02 2008-10-16 Nokia Corp Authentifizierungsverfahren und system
CN1385051A (zh) 1999-08-31 2002-12-11 艾利森电话股份有限公司 用于分组数据网络的全球移动通信***安全性
US6775262B1 (en) * 2000-03-10 2004-08-10 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for mapping an IP address to an MSISDN number within a wireless application processing network
EP1264463A2 (en) 2000-03-17 2002-12-11 AT & T Corp. Web-based single-sign-on authentication mechanism
FI20000760A0 (fi) * 2000-03-31 2000-03-31 Nokia Corp Autentikointi pakettidataverkossa
US7444513B2 (en) * 2001-05-14 2008-10-28 Nokia Corporiation Authentication in data communication
JP4301482B2 (ja) * 2001-06-26 2009-07-22 インターナショナル・ビジネス・マシーンズ・コーポレーション サーバ、情報処理装置及びそのアクセス制御システム並びにその方法
US7221935B2 (en) * 2002-02-28 2007-05-22 Telefonaktiebolaget Lm Ericsson (Publ) System, method and apparatus for federated single sign-on services
US20040064442A1 (en) 2002-09-27 2004-04-01 Popovitch Steven Gregory Incremental search engine
ES2292676T3 (es) 2002-11-25 2008-03-16 T-Mobile Deutschland Gmbh Metodo y sistema para facilitar el acceso a una cuenta de correo electronico a traves de una red de comunicacon movil.
US20040128560A1 (en) * 2002-12-31 2004-07-01 Challener David Carroll Security system preventing computer access upon removal from a controlled area
MXPA05006470A (es) 2003-01-10 2005-09-30 Ericsson Telefon Ab L M Registro sencillo para usuarios de una red de radio de paquete que se mueven en una red de operario multinacional.
US20060264201A1 (en) * 2003-03-10 2006-11-23 Thomson Licensing S.A. Identity mapping mechanism in wlan access control with public authentication servers
AU2003256191A1 (en) * 2003-08-26 2005-03-10 Telefonaktiebolaget Lm Ericsson (Publ) Apparatus and method for authenticating a user when accessing to multimedia services
JP4300965B2 (ja) * 2003-10-09 2009-07-22 沖電気工業株式会社 サービスシステムおよびサービス提供方法
WO2005045649A1 (en) * 2003-11-07 2005-05-19 Telecom Italia S.P.A. Method and system for the authentication of a user of a data processing system
US7200383B2 (en) * 2004-04-26 2007-04-03 Nokia Corporation Subscriber authentication for unlicensed mobile access signaling

Also Published As

Publication number Publication date
JP4782139B2 (ja) 2011-09-28
JP2008518533A (ja) 2008-05-29
AR053529A1 (es) 2007-05-09
CN101069402A (zh) 2007-11-07
US20080127320A1 (en) 2008-05-29
WO2006045402A1 (en) 2006-05-04
CN101069402B (zh) 2010-11-03
BRPI0517521A (pt) 2008-10-14
US7954141B2 (en) 2011-05-31

Similar Documents

Publication Publication Date Title
JP4782139B2 (ja) モバイルユーザーをトランスペアレントに認証してウェブサービスにアクセスする方法及びシステム
JP4394682B2 (ja) 非信頼アクセスネットワークを介してシングルサインオン認証を行なう装置及び方法
US8959598B2 (en) Wireless device authentication between different networks
US8261078B2 (en) Access to services in a telecommunications network
JP4586071B2 (ja) 端末へのユーザポリシーの提供
EP2347560B1 (en) Secure access in a communication network
Matsunaga et al. Secure authentication system for public WLAN roaming
US20060264201A1 (en) Identity mapping mechanism in wlan access control with public authentication servers
US20160380999A1 (en) User Identifier Based Device, Identity and Activity Management System
CN103067337B (zh) 一种身份联合的方法、IdP、SP及***
JP2006515486A (ja) セルラ通信システムにおいて再認証を可能にする方法および装置
EP2638496B1 (en) Method and system for providing service access to a user
Keromytis Voice over IP: Risks, threats and vulnerabilities
KR100670791B1 (ko) Ａａａ 서버에서의 확장형 권한 검증 방법
WO2013023475A1 (zh) 共享网络中用户数据的方法和身份提供服务器
US20120106399A1 (en) Identity management system
Ventura Diameter: Next generations AAA protocol
EP1813078A1 (en) Method and system for transparently authenticating a mobile user to access web services
JP2004023166A (ja) モバイル通信サービスシステム
Veltri et al. DHCP-based authentication for mobile users/terminals in a wireless access network
Molinaro et al. DHCP/IPSec-based Security for Wireless Access Networks

Legal Events

Date Code Title Description
B15K Others concerning applications: alteration of classification

Ipc: H04L 29/12 (2006.01), H04L 29/06 (2006.01), H04W 1

B07A Application suspended after technical examination (opinion) [chapter 7.1 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 10 (DEZ) ANOS CONTADOS A PARTIR DE 09/04/2019, OBSERVADAS AS CONDICOES LEGAIS. (CO) 10 (DEZ) ANOS CONTADOS A PARTIR DE 09/04/2019, OBSERVADAS AS CONDICOES LEGAIS

B21F Lapse acc. art. 78, item iv - on non-payment of the annual fees in time

Free format text: REFERENTE A 18A ANUIDADE.

B24J Lapse because of non-payment of annual fees (definitively: art 78 iv lpi, resolution 113/2013 art. 12)

Free format text: EM VIRTUDE DA EXTINCAO PUBLICADA NA RPI 2742 DE 25-07-2023 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDA A EXTINCAO DA PATENTE E SEUS CERTIFICADOS, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013.