X.690
X.690 é um padrão ITU-T que especifica vários formatos de codificação ASN.1:
- Regras de codificação básica (BER)
- Regras de codificação canônica (CER)
- Regras de codificação distinta (DER)
As regras de codificação básica(BER) eram as regras originais estabelecidas pelo padrão ASN.1 para codificar informações abstratas em um fluxo de dados concreto. As regras, coletivamente referidas como sintaxe de transferência na linguagem ASN.1, especificam as sequências exatas de octeto que são usadas para codificar um determinado item de dados. A sintaxe define elementos como: as representações para tipos de dados básicos, a estrutura das informações de comprimento e os meios para definir tipos complexos ou compostos com base em tipos mais primitivos. A sintaxe, juntamente com dois subconjuntos (as regras de codificação canônica e as regras de codificação distinta), são definidas pelo documento de padrões X.690 do ITU-T (que faz parte da série de documentos da ASN.1).
Codificação BER
[editar | editar código-fonte]O formato para as regras básicas de codificação especifica um formato autoexplicativo e auto-delimitador para a codificação de estruturas de dados ASN.1. Cada elemento de dados é codificado como um identificador de tipo, uma descrição de comprimento, os elementos de dados reais e, quando necessário, um marcador de fim de conteúdo. Esses tipos de codificações são comumente chamados de tipo-comprimento-valor ou codificações TLV. Esse formato permite que um receptor decodifique as informações ASN.1 de um fluxo incompleto, sem exigir nenhum pré-conhecimento do tamanho, conteúdo ou significado semântico dos dados.[1]
Estrutura de codificação
[editar | editar código-fonte]A codificação dos dados geralmente consiste em quatro componentes que aparecem na seguinte ordem:
| Octetos identificadores Tipo |
Octetos de comprimento Comprimento |
Octetos de conteúdo Valor |
Octetos de fim de conteúdo |
Os octetos de fim de conteúdo são opcionais e usados apenas se a forma de comprimento indefinido for usada. O octeto conteúdo também pode ser omitido se não houver conteúdo para codificar (como no tipo NULL).
Octetos identificadores
[editar | editar código-fonte]Tipos
[editar | editar código-fonte]Os dados (especialmente membros de sequências e conjuntos e escolhas) podem ser marcados com um número de marca exclusivo (mostrado em ASN.1 entre colchetes []) para distinguir esses dados de outros membros. Essas marcas podem ser implícitas (onde são codificadas com a marca TLV de valor em vez de usar o tipo base como marca TLV) ou explícitas (onde a marca é usada em um TLV construído que envolve o TLV tipo base). O estilo de marcação padrão é explícito, a menos que implícito seja definido no nível de módulo ASN.1. Essas marcas têm uma classe padrão de contexto específico, mas que pode ser substituída usando um nome de classe na frente da marca.
A codificação de um valor de escolha é a mesma que a codificação de um valor de tipo escolhido. A codificação pode ser primitiva ou construída, dependendo do tipo escolhido. A marca usada nos octetos identificadores é a marca de tipo escolhido, conforme especificado na definição ASN.1 do tipo escolhido.
As seguintes marcas são nativas do ASN.1:
| Nome | Construção permitida | Número de marcação | |
|---|---|---|---|
| Decimal | Hexadecimal | ||
| End-of-Content (EOC) | Primitivo | 0 | 0 |
| BOOLEAN | Primitivo | 1 | 1 |
| INTEGER | Primitivo | 2 | 2 |
| BIT STRING | Ambos | 3 | 3 |
| OCTET STRING | Ambos | 4 | 4 |
| NULL | Primitivo | 5 | 5 |
| OBJECT IDENTIFIER | Primitivo | 6 | 6 |
| Object Descriptor | Ambos | 7 | 7 |
| EXTERNAL | Construído | 8 | 8 |
| REAL (float) | Primitivo | 9 | 9 |
| ENUMERATED | Primitivo | 10 | A |
| EMBEDDED PDV | Construído | 11 | B |
| UTF8String | Ambos | 12 | C |
| RELATIVE-OID | Primitivo | 13 | D |
| TIME | Primitivo | 14 | E |
| Reserved | 15 | F | |
| SEQUENCE and SEQUENCE OF | Construído | 16 | 10 |
| SET and SET OF | Construído | 17 | 11 |
| NumericString | Ambos | 18 | 12 |
| PrintableString | Ambos | 19 | 13 |
| T61String | Ambos | 20 | 14 |
| VideotexString | Ambos | 21 | 15 |
| IA5String | Ambos | 22 | 16 |
| UTCTime | Ambos | 23 | 17 |
| GeneralizedTime | Ambos | 24 | 18 |
| GraphicString | Ambos | 25 | 19 |
| VisibleString | Ambos | 26 | 1A |
| GeneralString | Ambos | 27 | 1B |
| UniversalString | Ambos | 28 | 1C |
| CHARACTER STRING | Construído | 29 | 1D |
| BMPString | Ambos | 30 | 1E |
| DATE | Primitivo | 31 | 1F |
| TIME-OF-DAY | Primitivo | 32 | 20 |
| DATE-TIME | Primitivo | 33 | 21 |
| DURATION | Primitivo | 34 | 22 |
| OID-IRI | Primitivo | 35 | 23 |
| RELATIVE-OID-IRI | Primitivo | 36 | 24 |
A lista de atribuições de tag de classe universal pode ser encontrada em Rec. ITU-T X.680, cláusula 8, tabela 1.[2]
Codificação
[editar | editar código-fonte]Os octetos identificadores codificam o elemento tipo como uma marca ASN.1, consistindo de classe e número, e se os octetos de conteúdo representam um valor construído ou primitivo. Observe que alguns tipos podem ter valores com codificações primitivas ou construídas. Ele é codificado como 1 ou mais octetos.
| Octeto 1 | Octeto 2 em diante | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
| Classe de marcação | P/C | Número de marcação (0 à 30) | — | ||||||||||||
| 31 | Mais | Número de marcação | |||||||||||||
No octeto inicial, o bit 6 codifica se o tipo é primitivo ou construído, o bit 7–8 codifica a classe do tipo e os bits 1–5 codificam o número da etiqueta. Os seguintes valores são possíveis:
| Classe | Valor | Descrição |
|---|---|---|
| Universal | 0 | O tipo é nativo para ASN.1 |
| Aplicação | 1 | O tipo é válido apenas para um aplicativo específico |
| Específico do contexto | 2 | O significado deste tipo depende do contexto (como em uma sequência, conjunto ou escolha) |
| Privada | 3 | Definido em especificações privadas |
| P/C | Valor | Descrição |
|---|---|---|
| Primitivo (P) | 0 | Os octetos de conteúdo codificam diretamente o valor de elemento. |
| Construído (C) | 1 | Os octetos de conteúdo contêm 0, 1 ou mais codificações de elemento. |
Forma longa
[editar | editar código-fonte]Se o número de marcação for muito grande para o campo de marcação de 5 bits, ele deve ser codificado em outros octetos.
O octeto inicial codifica a classe e o primitivo/construído como antes e os bits 1 à 5 são 1. O número de marcação é codificado nos octetos seguintes, onde o bit 8 de cada um é 1 se houver mais octetos, e os bits 1 à 7 codificam o número de marcação. Os bits do número de marcação combinados, big-endian, codificam o número de marcação. O menor número dos octetos seguintes deve ser codificado, ou seja, os bits 1 à 7 não devem ser todos 0 no primeiro octeto seguinte.
Octetos de comprimento
[editar | editar código-fonte]Existem duas formas de octetos de comprimento: a forma definida e a forma indefinida.
| Forma | Bits | |||||||
|---|---|---|---|---|---|---|---|---|
| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | |
| Definido, curto | 0 | Comprimento (0–127) | ||||||
| Indefinido | 1 | 0 | ||||||
| Definido, longo | 1 | Número dos octetos seguintes (1–126) | ||||||
| Reservado | 1 | 127 | ||||||
Forma definitiva
[editar | editar código-fonte]Isso codifica o número de octetos de conteúdo e é sempre usado se o tipo for primitivo ou construído e os dados estiverem imediatamente disponíveis. Existe uma forma curta e uma forma longa, que podem codificar diferentes intervalos de comprimentos. Os dados numéricos são codificados como inteiros sem sinal, com o bit menos significativo sempre primeiro (à direita).
A forma abreviada consiste em um único octeto em que o bit 8 é 0 e os bits 1 à 7 codificam o comprimento (que pode ser 0) como um número de octetos.
A forma longa consiste em 1 octeto inicial seguido por 1 ou mais octetos subsequentes, contendo o comprimento. No octeto inicial, o bit 8 é 1 e os bits 1 à 7 (excluindo os valores 0 e 127) codificam o número de octetos que se seguem.[1] Os seguintes octetos codificam, como big-endian, o comprimento (que pode ser 0) como um número de octetos.
| Octeto 1 | Octeto 2 | Octeto 3 | |||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 1 | 1 | 0 | 0 | 1 | 1 |
| Forma longa | 2 octetos de comprimento | 435 octetos de conteúdo | |||||||||||||||||||||
Forma indefinida
[editar | editar código-fonte]Isso não codifica o comprimento, mas os octetos de conteúdo terminam nos octetos do marcador. Isso se aplica a tipos construídos e normalmente é usado se o conteúdo não estiver imediatamente disponível no momento da codificação.
Ele consiste em um único octeto, no qual o bit 8 é 1 e os bits 1 à 7 são 0. Então, 2 octetos de fim de conteúdo devem encerrar os octetos de conteúdo.
Octetos de conteúdo
[editar | editar código-fonte]Os octetos de conteúdo codificam o valor dos dados de elemento.[1]
Observe que pode não haver octetos de conteúdo (portanto, o elemento tem um comprimento de 0) se apenas a existência do objeto ASN.1, ou sua vacuidade, for observada. Por exemplo, esse é o caso de um valor ASN.1 NULL.
Codificação CER
[editar | editar código-fonte]As regras de codificação canônica (CER) são uma variante restrita das regras de codificação básica (BER) para a produção de sintaxe de transferência inequívoca para estruturas de dados descritas pela ASN.1. Enquanto as regras de codificação básica (BER) oferecem opções de como os valores dos dados podem ser codificados, as regras de codificação canônica (CER) (junto com as regras de codificação distinta (DER)) selecionam apenas uma codificação das permitidas pelas regras de codificação básicas, eliminando o restante das opções. As regras de codificação canônica (CER) são úteis quando as codificações devem ser preservadas (por exemplo, em trocas de segurança).
Codificação DER
[editar | editar código-fonte]As regras de codificação distinta (DER) são uma variante restrita das regras de codificação básica (BER) para a produção de sintaxe de transferência inequívoca para estruturas de dados descritas pela ASN.1. Assim como as regras de codificação canônica (CER) , as codificações DER são codificações BER válidas. As regras de codificação distinta (DER) são a mesma coisa que as regras de codificação básica (BER), com todas as opções de remetente removidas, exceto uma.
As regras de codificação distinta (DER) são um subconjunto de regras de codificação básica (BER) que fornece exatamente uma maneira de codificar um valor ASN.1. As regras de codificação distinta (DER) se destinam à situações em que uma codificação exclusiva é necessária, como em criptografia, e garante que uma estrutura de dados que precisa ser assinada digitalmente produza uma representação serializada exclusiva. As regras de codificação distinta (DER) podem ser consideradas uma forma canônica das regras de codificação básica (BER). Por exemplo, nas regras de codificação básica (BER), um valor boolean de true pode ser codificado como qualquer um dos 255 valores de byte diferentes de zero, enquanto nas regras de codificação distinta (DER) há apenas uma maneira de codificar um valor booleano de true.
As restrições de codificação DER mais significativas são:
- A codificação de comprimento deve usar a forma definitiva.
- Além disso, a codificação de comprimento mais curto possível deve ser usada.
- Bitstring, octetstring e strings de caracteres restritos devem usar a codificação primitiva.
- Elementos de um conjunto são codificados em ordem classificada, com base em seu valor de tag.
As regras de codificação distinta (DER) são amplamente usadas para certificados digitais (como o X.509).
BER, CER e DER comparados
[editar | editar código-fonte]A principal diferença entre o formato BER e os formatos CER ou DER é a flexibilidade fornecida pelas regras de codificação básica. BER, como explicado acima, é o conjunto básico de regras de codificação fornecidas por ITU-T X.690 para a transferência de estruturas de dados ASN.1. Ele fornece aos remetentes regras claras para a codificação das estruturas de dados que eles desejam enviar, mas também deixa aos remetentes algumas opções de codificação. Conforme declarado no padrão X.690, "codificações alternativas são permitidas pelas regras de codificação básica como opção do remetente. Os receptores que alegam conformidade com as regras de codificação básica devem oferecer suporte à todas as alternativas". [1]
Um receptor deve estar preparado para aceitar todas as codificações legais para alegar legitimamente a conformidade com as BER. Por outro lado, as CER e DER restringem as especificações de comprimento disponíveis à uma única opção. Como tal, as CER e DER são formas restritas de BER e servem para eliminar a ambiguidade do padrão de BER.
CER e DER diferem no conjunto de restrições que colocam no remetente. A diferença básica entre CER e DER é que as DER usam forma de comprimento definitivo e as CER usam forma de comprimento indefinido em alguns casos precisamente definidos. Ou seja, as DER sempre têm informações de comprimento inicial, enquanto as CER usa octetos de fim de conteúdo em vez de fornecer o comprimento dos dados codificados. Por causa disso, ad CER requerem menos metadados para grandes valores codificados, enquanto as DER os fazem para os pequenos.
A fim de facilitar a escolha entre as regras de codificação, o documento de padrões X.690 fornece a seguinte orientação:
As regras de codificação distinta são mais adequadas do que as regras de codificação canônica se o valor codificado for pequeno o suficiente para caber na memória disponível e houver uma necessidade de pular rapidamente alguns valores aninhados. As regras de codificação canônica são mais adequadas do que as regras de codificação distinta se houver necessidade de codificar valores tão grandes que não possam caber prontamente na memória disponível ou se for necessário codificar e transmitir uma parte de um valor antes de todo o valor estar disponível. As regras de codificação básica são mais adequadas do que as regras de codificação canônica ou distinta se a codificação contiver um valor conjunto ou valor de conjunto e não houver necessidade das restrições que as regras de codificação canônica e distinta impõem.
Críticas à codificação BER
[editar | editar código-fonte]Há uma percepção comum de BER como sendo "ineficiente" em comparação com regras de codificação alternativas. Tem sido argumentado por alguns que essa percepção é principalmente devido à implementações pobres, não necessariamente à qualquer falha inerente nas regras de codificação.[3] Essas implementações contam com a flexibilidade que as BER fornecem para usar a lógica de codificação que é mais fácil de implementar, mas resultam em um fluxo de dados codificados maior do que o necessário. Seja essa ineficiência realidade ou percepção, ela levou à uma série de esquemas de codificação alternativos, como as regras de codificação empacotada, que tentam melhorar o desempenho e o tamanho das BER.
Outras regras de formatação alternativas, que ainda fornecem a flexibilidade das BER, mas usam esquemas de codificação alternativos, também estão sendo desenvolvidas. As mais populares são alternativas baseadas em XML, como as regras de codificação XML e a ASN.1 SOAP.[4] Além disso, há um mapeamento padrão para converter um esquema XML em um esquema ASN.1, que pode então ser codificado usando as BER.[5]
Uso
[editar | editar código-fonte]Apesar de seus problemas percebidos, as BER são um formato popular para transmissão de dados, particularmente em sistemas com diferentes codificações de dados nativos.
- Os protocolos SNMP e LDAP especificam a ASN.1 com as BER como seu esquema de codificação necessário.
- O padrão EMV para cartões de crédito e débito usa as BER para codificar dados no cartão.
- O padrão de assinatura digital PKCS #7 também especifica a ASN.1 com as BER para codificar mensagens criptografadas e sua assinatura ou envelope digital.
- Muitos sistemas de telecomunicações, como a ISDN, o roteamento de chamadas gratuitas e a maioria dos serviços de telefone celular, usam a ASN.1 com as BER até certo ponto para transmitir mensagens de controle pela rede.
- Os arquivos GSM TAP (transferred account procedures
- procedimentos de conta transferida) e NRTRDE (near real time roaming data exchange - troca de dados em roaming quase em tempo real) são codificados usando BER. [1]
Em comparação, a codificação DER mais definida é amplamente usada para transferir certificados digitais como o X.509.
Ver também
[editar | editar código-fonte]- Kerberos
- Regras de codificação empacotada (PER, X.691)
- Camada de apresentação
- Formato de troca de dados estruturados (SDXF)
- Serialização
Referências
- ↑ a b c d Tecnologia da informação - Regras de codificação ASN.1: Especificação de regras de codificação básica (BER), regras de codificação canônica (CER) e regras de codificação distinta (DER), ITU-T X6.90, 07/2002
- ↑ http://itu.int/ITU-T/X.680
- ↑ Lin, Huai-An. “Estimativa do desempenho ideal da sintaxe de transferência ASN.1/BER ”. Análise da comunicação de computador ACM. Julho 93, 45 - 58.
- ↑ ITU-T Rec. X.892, ISO/IEC 24824-2
- ↑ ITU-T X.694, ISO/IEC ISO/IEC 8825-5
Ligações externas
[editar | editar código-fonte]- 'Guia de um leigo a um subconjunto de ASN.1, BER e DER' RSA.
- ITU-T X.690, ISO/IEC 8825-1
- ITU-T X.892, ISO/IEC 24824-2
- ITU-T X.694, ISO/IEC ISO/IEC 8825-5
- PKCS #7.
- jASN1 Biblioteca de codificação ASN.1 BER/DER Java de código aberto (por beanit).
- PHPASN1 Biblioteca de codificação/decodificação ASN.1 BER PHP no github, com licença GPL.
- ASN1js Biblioteca de codificação/decodificação ASN.1 BER JavaScript no github, com licença GPL.
- Guia de estilo X.509 de Peter Gutmann.