WirelessBR

(Esta página contém figuras grandes. Aguarde a carga se a conexão estiver lenta)

3.0 WTLS

3.1 – Descrição Geral 

O Protocolo da Camada de Segurança na arquitetura WAP provê para as camadas superiores um serviço de interface de transporte seguro, preservando o serviço de interface de transporte abaixo dele. A camada WTLS é modular, isto é, o seu uso ou não depende do nível de segurança requerido em uma dada aplicação. Ou seja, é uma camada opcional da pilha WAP. Além da segurança, o WTLS fornece uma interface para gerenciamento de conexões seguras.

 O objetivo primordial da camada WTLS é fornecer privacidade, integridade de dados e autenticação entre duas aplicações. O WTLS provê funcionalidade similar ao TLS 1.0, além de adicionar novas funcionalidades, como suporte a datagrama, handshake otimizado, e atualização de chave dinâmica, e ser otimizado para redes de banda estreita com grande latência.

3.2 – Serviço de Transporte 

O Serviço de Transporte do WTLS utiliza o serviço primitivo SEC-Unitdata para trocar dados do usuário entre os pontos. Este serviço só pode ser solicitado quando há uma conexão segura entre os endereços de transporte dos pontos. Para tanto, faz-se necessário o uso de cinco parâmetros: 

1. O endereço de origem, que identifica o solicitante da conexão;

 2. A porta de origem, que identifica a porta de onde a mensagem será enviada;

3. O endereço de destino, que identifica o ponto para o qual os dados do usuário serão enviados;

4. A porta de destino, que identifica a porta pela qual a mensagem será enviada;

5. Os dados do usuário, que são os dados que serão transmitidos.

3.3 Gerenciamento de Conexão

 O Gerenciamento de Conexão do WTLS permite ao cliente conectar-se com um servidor e concordar com as opções do protocolo a serem usadas. O estabelecimento da conexão segura consiste de uma série de passos e tanto o cliente quanto o servidor podem interromper a negociação de acordo com a sua vontade, como por exemplo se os parâmetros propostos pelo ponto não forem aceitáveis. A negociação pode incluir os parâmetros de segurança, como algoritmos de criptografia, tamanho de chaves, troca de chave e autenticação. As Figuras 10 e 11 mostram dois exemplos de conexão, a primeira com handshake completo e a segunda com o handshake abreviado ou otimizado.

Figura 10: Handshake Completo

Figura 11: Handshake Abreviado

Assim como o Serviço de Transporte, que usa o serviço primitivo SEC-UnitData, o Gerenciamento de Conexão também faz uso deste tipo de serviço para otimizar suas tarefas:

 ·  SEC-Create: É usado para iniciar o estabelecimento de uma conexão segura. A Tabela 3 lista os parâmetros deste serviço com suas respectivas descrições.

Tabela 3: Parâmetros do Serviço SEC-Create

 ·      SEC-Exchange: É usado para a criação da conexão se o servidor deseja realizar a autenticação de chave pública ou troca de chaves com o cliente. O único parâmetro deste serviço é descrito na Tabela 4. 

Tabela 4: Parâmetro do Serviço SEC-Exchange

     · SEC-Commit: É iniciado quando o handshake é completado e uma das requisições do ponto para trocar para o estado da conexão é recentemente negociada. Este serviço não possui parâmetros.

 · SEC-Terminate: É usado para encerrar a conexão. Este serviço possui dois parâmetros, conforme descrito na Tabela 5. 

Tabela 5: Parâmetros do Serviço SEC-Terminate

· SEC-Exception: É usado para informar à outra ponta sobre o nível dos alertas de aviso. Este serviço possui um único parâmetro, descrito na Tabela 6.

Tabela 6: Parâmetro do Serviço SEC-Exception

·  SEC-Create-Request: É usado pelo servidor para requisitar ao cliente o início de um novo handshake e possui os parâmetros listados na Tabela 7.

Tabela 7: Parâmetros do Serviço SEC-Request

3.4 – Protocolo de Registro

 O Protocolo de Registro pega as mensagens a serem transmitidas, opcionalmente, comprimem os dados, aplica um MAC (Message Authentication Code - Código de Autenticação de Mensagem) e transmite o resultado. Os dados recebidos são desencriptados, verificados e descomprimidos, se for o caso, e então entregues aos níveis-clientes acima.

 O ambiente de operação do Protocolo de Registro é o Estado de Conexão, que especifica os algoritmos de compressão, de encriptação e de MAC a serem usados. Existem somente dois estados de conexão indicados pelo ambiente de operação - o estado corrente e o estado pendente, e todos os registros são processados sob o estado corrente. Os parâmetros de segurança para o estado pendente são setados pelo Protocolo de Handshake, que deve tornar o estado pendente em corrente. Quando isto ocorre o estado pendente é reinicializado para um estado vazio, o qual, por padrão, não tem especificado nenhuma encriptação, compressão ou MAC.

3.5 Protocolo de Handshake

 O Protocolo de Handshake é formado por três subprotocolos que são usados para permitir os pontos concordarem sobre os parâmetros de segurança para a Camada de Registro, autenticando-se, instanciar os parâmetros de segurança negociados e reportar condições de erros. É este protocolo que é responsável por negociar uma sessão segura.

 O primeiro dos três subprotocolos é o Protocolo de Especificação de Mudança de Algoritmo de Criptografia, que existe para sinalizar transições nas estratégias destes algoritmos. O protocolo consiste de uma mensagem, que é criptografada e comprimida sob o estado de conexão corrente. A especificação de mudança de algoritomo de criptografia é enviada pelo cliente ou pelo servidor para notificar a outra parte que os registros seguintes serão protegidos sob um novo algoritmo e novas chaves.

 O segundo subprotocolo é o Protocolo de Alerta, que transporta as mensagens de alerta com seu grau de severidade e uma descrição do alerta. Se a mensagem de alerta com um nível de “fatal” resulta num término imediato da conexão segura, mas outras conexões usando a sessão segura podem continuar, o identificador de sessão deve ser invalidado a fim de prevenir que a sessão com falha de segurança seja usada para estabelecer novas conexões seguras. Se a mensagem de alerta for de nível “crítico”, a conexão segura é imediatamente fechada, mas outras conexões seguras podem continuar utilizando a sessão segura. Nesse caso, o identificador de sessão pode continuar a ser usado pelas conexões e o identificador de sessão pode ser preservado para o estabelecimento de novas sessões seguras.

 O terceiro é o subprotocolo handshake que é o que realmente faz o primeiro contato do cliente com o servidor, no qual estes concordam em que versão do protocolo usar, qual algoritmo de criptografia irão selecionar, opcionalmente autenticam-se e, por último, usam as técnicas de encriptação por chave pública para compartilharem algum dado secreto.

 O Protocolo de Handshake do WTLS envolve os seguintes passos:

1. Troca de mensagens de “olá” para o acordo de algoritmos e troca de valores randômicos.

2. Troca dos parâmetros criptográficos necessários para permitir ao cliente e ao servidor concordarem em um segredo inicial.

3. Troca de certificados e informação criptográfica para permitir ao cliente e ao servidor autenticarem-se entre si. 

4. Geração de um segredo principal a partir segredo inicial e dos valores trocados randomicamente. 

5. Provisão dos parâmetros de segurança para a Camada de Registro.

6. Permissão ao cliente e ao servidor para verificar se os seus pontos foram calculados pelos mesmos parâmetros de segurança e se o handshake ocorreu sem intervenção de um atacante. 

Em um ambiente de datagrama, as mensagens de handshake podem ser perdidas, não funcionarem ou serem duplicadas. A fim de torná-las mais confiáveis, o WTLS requer que:

 a)  as mensagens de handshake indo a uma mesma direção sejam concatenadas em uma única SDU (Service Data Unit - Unidade de Serviço de Dados);

 b)  o cliente retransmita as mensagens de handshake, se necessário; e

 c)  o servidor responda apropriadamente às mensagens retransmitidas do cliente.

3.6 – WIM

 O WIM (WAP Identity Module - Módulo de Identidade WAP) é usado pelo WTLS e pelas operações de nível de segurança das aplicações especialmente para armazenar e processar as informações necessárias para a identificação e autenticação do usuário. Um exemplo de implementação do WIM pode ser um smart card. Em um telefone, ele poderia ser o cartão SIM (Subscriber Identity Module - Módulo de Identidade do Assinante) ou um smart card externo.

 Para o WTLS, o WIM é usado para a realização de operações criptográficas durante os handshakes, especialmente aqueles que são usados para a autenticação do cliente e para segurança de sessões WTLS de longa duração.

 O WIM é usado para proteção permanente de chaves privadas. Ele armazena estas chaves e realiza operações de sinalização para autenticação do cliente, quando necessário para um esquema de handshake selecionado e de troca de chave usando uma chave fixa do cliente. Em ambas operações ele usa as chaves privadas. O WIM também pode armazenar certificados (certificados do usuários e de jurisdição).  

O WIM suporta, adicionalmente, o cálculo ou geração do segredo inicial, cálculo e armazenagem do segredo principal para cada sessão segura e derivação e saída da chave material, baseada no segredo principal.

 Para as operações de nível de segurança das aplicações, o WIM inclui a assinatura e a abertura de uma chave. Ambas as operações usam a chave privada, que nunca deixa o WIM e estas operações pretendem ser genéricas de maneira a servirem para qualquer aplicação definida no WAP, como, por exemplo, uma usando o WMLScript, ou fora do WAP. 

A operação de abertura de chave é necessária quando uma aplicação recebe um chave de mensagem encriptada com uma chave pública que corresponde a uma chave privada no WIM. O dispositivo móvel envia a chave “fechada” para o WIM, este a decifra usando a chave privada e retorna a chave “aberta”. O dispositivo móvel pode usar esta chave “aberta” para decifrar uma mensagem.

 A operação de assinatura digital pode ser usada para propósitos de autenticação ou não-repúdio. Para o não-repúdio, uma chave separada é normalmente usada e ao usuário é requisitado a entrada de informações de autenticação para cada assinatura feita. Para suportar o não-repúdio, a chave de assinatura nunca deve deixar o dispositivo resistente à intervenção de terceiros. Para a assinatura de alguns dados, o dispositivo móvel calcula uma parte dos dados, formata-a de acordo com os requisitos da aplicação e envia o pedaço formatado para o WIM; este, então, calcula a assinatura digital usando a chave privada e retorna a assinatura digital.