Protocolo de Segurança IP (IP Security Protocol, mais conhecido pela sua sigla, IPsec) é uma extensão do protocolo IP que visa a ser o método padrão para o fornecimento de privacidade do usuário (aumentando a confiabilidade das informações fornecidas pelo usuário para uma localidade da internet, como bancos), integridade dos dados (garantindo que o conteúdo que chegou ao seu destino seja o mesmo da origem) e autenticidade das informações ou prevenção de identity spoofing (garantia de que uma pessoa é quem diz ser), quando se transferem informações através de redes IP pela internet.

Segundo a RFC 6071, IPsec é uma suíte de protocolos que provê segurança no nível da camada IP para comunicações pela Internet.[1] Opera na camada de rede (ou camada 3) do modelo OSI, sendo essa a camada de mesmo nome no modelo TCP/IP. Outros protocolos de segurança da internet como SSL e TLS operam desde a camada de transporte (camada 4) até a camada de aplicação (camada 7).

Isso torna o IPsec mais flexível, como pode ser usado protegendo os protocolos TCP e UDP, mas aumentando sua complexidade e despesas gerais de processamento porque não se pode confiar em TCP (camada 4 do modelo OSI) para controlar a confiabilidade e a fragmentação. O IPsec é parte obrigatória do IPv6, e opcional para o uso com IPv4. O padrão foi projetado para ser indiferente às versões do IP, à distribuição atual difundida e às implementações do IPv4.

História e desenvolvimento

editar

A RFC 1825, publicada em 1995, estabeleceu a arquitetura de segurança na camada de interredes da pilha TCP/IP (equivalente à camada de rede do modelo OSI) por meio da especificação dos protocolos AH (Autentication Header, "cabeçalho de autenticação") e ESP (Encapsulated Security Payload, "encapsulamento de segurança de carga útil"), cujos cabeçalhos seriam usados para prover serviços de segurança (autenticidade, integridade e confidencialidade) ao IPv4 e IPv6.[2] Detalhes de implementação destes dois protocolos foram inicialmente especificados nas RFC 1826 e RFC 1827.[3][3]

A RFC 1825 também definiu a necessidade de um protocolo de gerenciamento de chaves como necessário ao uso de AH ou ESP, bem como especificou o conceito de Security Association ("associação de segurança", ou simplesmente SA), um conjunto de informações que definem uma conexão, igualmente necessário em qualquer implementação dos protocolos AH e ESP. Foram ainda definidos o MD5 e o DES no modo CBC como algoritmos padrões do AH e ESP, respectivamente.

Em novembro 1998, uma série de RFCs foram publicadas (da RFC 2401 à RFC 2412), atualizando e estendendo as especificações da suíte de protocolos e ferramentas IPsec, por exemplo, introduzindo o protocolo IKE (Internet Key Exchange, "compartilhamento de chaves na Internet") como ferramenta de gerenciamento automático de chaves. Este conjunto de RFCs ficou conhecido como "antigo IPsec" ou "IPsec-v2". Em 2005 a arquitetura IPsec foi novamente renovada e expandida em uma terceira geração de RFCs (RFC 4301, 4302 e 4306, dentre outras), o que se convencionou chamar "IPsec-v3", ou "novo IPsec". Atualmente, o HMAC-SHA-1 e o AES-CBC de 128 bits são os algoritmos padrões para garantia de autenticidade, integridade e confidencialidade no IPsec, em substituição ao MD5 e ao DES.[1]

Características

editar

O IPsec é uma combinação de diferentes tecnologias criadas para prover uma segurança melhor, como um mecanismo de troca de chaves de Diffie-Hellman; criptografia de chave pública para assinar as trocas de chave de Diffie-Hellman, sendo assim, garantindo a integridade das partes e evitando ataques como o man-in-the-middle; algoritmos para grandes volumes de dados, com o DES; algoritmos para cálculo de hash como utilização de chaves, com o HMAC, junto com os algoritmos de hash tradicionais como o MD5 ou SHA, autenticando pacotes e certificados digitais assinados por uma autoridade certificadora, que agem como identidades digitais.[4]

Arquitetura de segurança

editar

IPsec é o protocolo de criptografia da internet para tunelamento, criptografia e autenticação. Existem dois modos, consoante a unidade o que se está protegendo. No modo transporte se protege o conteúdo útil do pacote IP e no modo túnel se protege o pacote IP completo.

Modo de transporte

editar

No modo transporte, somente a mensagem (payload) é criptografada. O roteamento permanece intacto, desde que o cabeçalho do IP não seja modificado e nem cifrado; entretanto, quando o cabeçalho da autenticação é usado, os endereços IP não podem ser traduzidos, porque isto invalida o valor de hash. As camadas de transporte e de aplicação são fixas sempre pelo hash, assim, não podem sofrer nenhuma modificação. O modo transporte é usado para comunicações de host-a-host.

Modo de tunelamento

editar

No modo de tunelamento, o pacote IP é criptografado por inteiro. Deve, assim, encapsular um novo pacote IP para distribuí-lo. O tunelamento é usado para comunicações da rede-a-rede (túneis seguros entre roteadores) ou comunicações de host-a-rede e de host-a-host sobre a internet.

Características técnicas do IPsec

editar

Dois protocolos foram desenvolvidos para prover um nível de segurança para os fluxos dos pacotes e mudanças de chaves como:

  • Encapsulating Security Payload (ESP), que provê autenticação, confidencialidade dos dados e integridade da mensagem.
  • Cabeçalho de autenticação (AH), que provê a autenticação e integridade dos dados, mas não a confidencialidade.

Cabeçalho de autenticação (AH)

editar
0 - 7 bit 8 - 15 bit 16 - 23 bit 24 - 31 bit
Próximo cabeçalho Tamanho da mensagem RESERVADO
Identificação dos Parâmetros de Segurança (SPI)
Número de Sequência
Dados de autenticação (variável)

Descrição dos campos:

  • Próximo cabeçalho: Identifica o protocolo de dados de transferência;
  • Tamanho da mensagem: Tamanho do cabeçalho AH;
  • RESERVADO: reservado para uso futuro;
  • Identificação dos parâmetros de segurança (SPI): a identificação dos parâmetros de segurança (SPI) que, em combinação com o endereço IP, identifica a Associação de Segurança (SA) implementada para este pacote;
  • Número de sequência: um número crescente, usado para impedir ataques repetitivos;
  • Dados de autenticação: contém o valor da verificação da integridade (ICV) necessário para autenticação do pacote.

Encapsulating Security Payload (ESP)

editar

O diagrama ESP:

0 - 7 bit 8 - 15 bit 16 - 23 bit 24 - 31 bit
Identificação dos Parâmetros de Segurança (SPI)
Número de Sequência
Dados de payload (variável)
  Padding (0-255 bytes)  
    Tamanho do Pad Próximo cabeçalho
Dados de autenticação (variável)

Descrição dos campos:

  • Identificação dos parâmetros de segurança (SPI): identifica os parâmetros de segurança em combinação com o endereço de IP;
  • Número de sequência: um número crescente, usado para impedir ataques repetitivos;
  • dados da mensagem: os dados a serem transferidos;
  • Padding: usado por alguns algoritmos criptográficos para reordenar por inteiro o conteúdo dos blocos;
  • Tamanho do pad: tamanho do pad em bytes;
  • Próximo cabeçalho: identifica o protocolo para transferência dos dados;
  • Dados de autenticação: contém os dados usados para autenticação do pacote.

Implementações

editar

O suporte ao IPsec é geralmente incluído no núcleo do sistema operacional com gerência de chave e ISAKMP/IKE entre as negociações realizadas no espaço do usuário-final. Existem implementações do IPsec que tendem a incluir ambas as funcionalidades. Entretanto, porque há uma relação padrão para a gerência de chave, é possível controlar uma pilha do IPsec no núcleo usando uma ferramenta de gerência de chave com implementação diferente.

Por esta causa, há confusão a respeito das origens da implementação do IPsec que está no núcleo Linux. FreeS/WAN é o projeto que primeiro implementou uma solução completa e de código aberto do IPsec para Linux, e o projeto foi encerrado em março de 2004. Openswan e strongSwan são as continuações do FreeS/WAN. KAME project também implementou um suporte completo ao IPsec para o NetBSD e FreeBSD. O OpenBSD fez seu próprio daemon de ISAKMP/IKE, nomeado simplesmente como isakmpd (que foi movido também a outros sistemas, incluindo Linux).

Entretanto, nenhumas destas pilhas do IPsec foram integradas no Linux. Alexey Kuznetsov e David S. Moleiro escreveram uma implementação de IPsec para o Linux em torno do fim de 2002. Esta pilha foi liberada subsequentemente como parte do Linux 2.6.

Consequentemente, contrariando a opinião popular, a pilha do IPsec no Linux não se originou do projeto KAME. Como suporta o protocolo padrão PF KEY (RFC 2367) e a relação nativa XFRM para a gerência de chave, a pilha do IPsec no Linux pode ser usada conjuntamente com qualquer uma das implementações citadas abaixo.

Ver também

editar

Referências

Ligações externas

editar

📚 Artikel Terkait di Wikipedia

Douglas Comer

0-13-233553-0 Automated Network Management Systems, 2006. ISBN 0-13-239308-5 Network Systems Design Using Network Processors, Intel 2xxx version, 2006

Bluetooth Low Energy

arquivada em 4 de agosto de 2016  «BlueNRG-MS – Bluetooth Low Energy Network Processor supporting Bluetooth 4.1 core specification – STMicroelectronics»

Formato de ponto flutuante bfloat16

de maio de 2018). «Intel To Launch Spring Crest, Its First Neural Network Processor, In 2019». Tom's Hardware. Consultado em 23 de maio de 2018  «Available

ARPANET

William; Walden, David (1970). The Interface Message Processor for the ARPA Computer Network (PDF). EUA: AFIPS Proc. p. 565. doi:10.1145/1476936.1477021

Microprocessador softcore

FPGAs". 1998. [1] Zhoukun WANG and Omar HAMMAMI. "A 24 Processors System on Chip FPGA Design with Network on Chip". [2] John Kent. "Micro16 Array - A Simple

9to5Mac

video over USB-C, AirPod-like Apple Pencil 2 pairing, more [Update: A12X processor] - 9to5Mac». 4 de junho de 2021. Consultado em 11 de abril de 2023. Cópia

Dispositivo multigate

technology». 22 de março de 2017  «Samsung and eSilicon Taped Out 14nm Network Processor with Rambus 28G SerDes Solution». 22 de março de 2017  Colinge, J

PlayStation 3

 15 de 18. To increase fabrication yelds, Sony ships PlayStation 3 Cell processors with only seven working SPEs. And from those seven, one SPE will be used