primeiro módulo Introdução, ASN.1, BER e DER
segundo módulo PKCS#1v2.1, PKCS#8
terceiro módulo Certificados e CRLs X.509

Roteiro Quarto Módulo

C2-4  Os padrões PKCS#7 e PKCS#12
 

Como explicado no módulo 2, as recomendações de padronização propostas pela empresa que deteve, até setembro de 2000, a patente sobre o algoritmo RSA, são conhecidas pela sigla PKCS (Public Key Cryptographic Stantards), recomendações essas que se tornaram padrões de fato em PKIs, sendo o algoritmo RSA o de uso mais disseminado. Neste módulo iremos abordar os padrões PKCS #7 e 12. O PKCS#7 estabelece um padrão de sintaxe para mensagens cifradas (visando sigilo, autenticação ou ambas: “Cryptographic Message Syntax Standard”),  e PKCS #12, estabelece um padrão de sintaxe para intercâmbio de informações pessoais. ("Personal Information Exchange Syntax Standard”)

   C2-4.1 O padrão PKCS#7 para sintaxe de mensagens cifradas

C2-4.1.1- Evolução e versões do PKCS#7

A primeira versão do padrão PKCS#7 a se tornar pública foi a versão 1.4. Em 3 de junho de 1991, foi publicada como documento do Workshop de desenvolvedores NIST/OSI sob a sigla SEC-SIG-91-22. Depois, em 1 de Novembro de 1993, foi publicada a versão 1.5, que, além de um histórico de revisão, incluiu e revisou alguns tipos de dados, para acomodar as demandas de padronização em PKIs operando através da Internet [7].

A versão 1.5 buscava, em particular, o alinhamento com os padrões PEM, definidos pelo IETF visando interoperabilidade de protocolos e aplicações de correio eletrônico com requisitos de segurança. Porém, devido à "ecologia" da evolução de padrões na Internet, acabou por embasar o desenvolvimento de padrões alternativos, hoje bem mais populares nesses protocolos e aplicações: as extensões S/MIME verões 2 e 3. O PKCS #7 influiu não apenas na evolução do S/MIME, mas também em outros protocolos de aplicação criptográfica, como o SET, o W3C Digital Signature Iniciative, e o PCKS#12.[8]

 
Neste processo, a especificação 1.5 não aclarava a possibilidade das aplicações estenderem os tipos de dados especificados. Com o advento do protocolo SET esta possibilidade se tornou necessária, precipitando uma pequena revisão da versão 1.5, que veio a ser conhecida como 1.6. A versão 1.6 está documentada em "Extension Revisions to PKCS#7", de 13 de maio de 1997 [8], onde as modificações e questões de interoperabilidade entre as versões 1.6 e 1.5 são mapeadas, bem como um plano traçado para a versão 2.0, contemplando, dentre outras necessidades, uma maior independência dos padrões ao algoritmo RSA.

As aplicações que foram definidas a partir da v1.5, como S/MIME por exemplo, não precisam migrar para a v1.6. Doutra feita, o suporte ao formato PKCS#6 para certificados foi descontinuado na v1.6, à luz da introdução de extensões na v.3 do padrão X.509. Mas a documentação final da versão 1.6, ou mesmo a versão 2.0, ainda não haviam vindo a público, quando da elaboração deste módulo (27/09/03), que se baseia portanto no padrão 1.5 (em [7]), com breves referências à revisão 1.6.

C2-4.1.2 - Escopo do PKCS#7

O padrão PKCS#7 descreve uma sintaxe genérica para dados que podem ser submetidos a funções criptográficas, tais como assinatura e envelopagem digital. Permite recursividade, com aninhamento de envelopes e wrappers. Permite também a associação de atributos arbitrários, como por exemplo selo temporal ou contra-assinatura, à mensagem no processo de autenticação por assinatura. Casos particulares oferecem meios de disseminação de certificados e CRLs.

O padrão PKCS#7 pode dar suporte a uma variedade de arquiteturas de gerenciamento de chaves baseadas em ICP, como aquela proposta para o padrão PEM na RFC 1422. Entretanto, topologias, modelos de confiança e políticas de certificação para ICPs estão fora do seu escopo. Valores produzidos pelo padrão pretendem-se destinados à codificação DER, ou seja, para transmissão e armazenagem na forma de cadeias de octetos de comprimento não necessariamente conhecidos de antemão.

Portanto, recodificação para transmissão por protocolos que restringem a ocorrência de certos octetos, como por exemplo, cadeias de caracteres ASCII (SMTP), não são contemplados, embora possam ser encapsulados em recodificadores como os descritos no RFC 1421.
 

C2-4.2.1- Notação

Os seguintes termos são empregados nos documentos que definem o padrão PKCS#7
 

Notação para o PKCS#7

Termo	Definição
AlgorithmIdentifier:	Tipo que define um algoritmo por meio de um identificador de objeto (OID) e parâmetros associados. Como definido em X.509.
ASN.1 .	Abstract Syntax Notation One, como definida em X.208
Attribute:	Tipo que contém um tipo de atributo (especificado por um identificador de objeto) e um ou mais valores de atributo. Como definido em X.501. (ISO/IEC 9594-2:1997. Information technology -- Open Systems Interconnection -- The Directory: Models. 1997)
BER:	Basic Encoding Rules, como definida em X.209.
Certificate:	Tipo de dado que vincula um nome unívoco de uma entidade a uma chave pública por meio de uma assinatura. Como definido em X.509, também contém um nome unívoco do emissor (signatário do certificado), número de série específico do emissor, identificador do algoritmo de assinatura e período de validade.
CertificateSerialNumber:	Tipo que identifica univocamente um certificado (e seus atributos) dentre aqueles assinados por um emissor em particular. Como definido em X.509
CertificateRevocationList:	Tipo que contém informação sobre ceritificados cuja validade o emissor (signatário) revogou prematuramente. Esta informação consiste no nome do emissor, data da emissão e da próxima emissão programada, e uma lista de números de série dos certificados revogados com a data de revogação. Como definido em RFC 1422.
DER:	Distinguished Encoding Rules para ASN.1, como definido em X.509, Seção 8.7.
DES:	Data Encryption Standard, como definido em FIPS PUB 46-1.
desCBC:	OID para o algoritmo DES em modo de cifragem cipher-block chaining (CBC) como definido em "Special Publication 500-202: Stable Implementation Agreements for Open Systems Interconnection Protocols", NIST, 1991
ExtendedCertificate:	Tipo de certificado definido em PKCS #6. [não mais em uso após v1.6]
MD2:	Algoritmo de hash da RSA Data Security, Inc., como definido em RFC 1319.
md2:	OID do algoritmo MD2, como definido em RFC 1319.
MD5:	Algoritmo de hash da RSA Data Security, Inc., como definido em RFC 1321.
md5:	OID do algoritmo MD2, como definido em RFC 1321.
Name:	Tipo que identifica univocamente objetos em um diretório X.500, como definido em X.501. Num certificado X.509, é empregado para identificar o titular da chave transportada e o emissor (signatário) do certificado.
PEM:	Internet Privacy-Enhanced Mail, como definido em RFCs 1421-1424.
RSA:	Algoritmo criptográfico assimétrico RSA, como definido em  R.L. Rivest, A. Shamir, and L. Adleman's. "A method for obtaining digital signatures and public-key cryptosystems". Communications of the ACM, 21(2):120-126, Fevereiro 1978..
rsaEncryption:	OID do algoritmo RSA, como definido em  PKCS #1

.
C2-4.2.2- Tipos úteis

Os seguintes tipos ASN.1 são empregados na especificação de sintaxes do padrão PKCS#7
 

Tipos para o PKCS#7

Tipo [versão 1.5] [versão 1.6]	Descrição
CertificateRevocationLists ::=   [SET OF] [SEQUENCE OF] CertificateRevocationList	Tipo definido para o transporte autenticado de um conjunto de CRLs, como conteúdo de uma mensagem assinada.
ContentEncryptionAlgorithmIdentifier ::=   AlgorithmIdentifier	Tipo definido para identificar um algoritmo de cifragem do conteúdo da mensagem, capaz de operar em modo de encriptação e decriptação (ex: DES)
DigestAlgorithmIdentifier ::= AlgorithmIdentifier	Tipo definido para identificar um algoritmo de hash, capaz de operar sobre cadeias de octetos produzindo digestos em formato cadeia de octetos (ex: MD2, MD5, SHA1, etc)
DigestEncryptionAlgorithmIdentifier ::=   AlgorithmIdentifier	Tipo definido para identificar um algoritmo de cifragem capaz de operar sobre cadeias de octetos que representam digestos de mensagem, em modo de encriptação ou decriptação, sob o controle de uma chave de cifra. O contexto determina qual das operações é pretendida (ex: rsaEncription)
ExtendedCertificateOrCertificate ::= CHOICE  {   certificate Certificate, -- X.509   [ extendedCertificate [0]      IMPLICIT ExtendedCertificate ] }	Tipo que dá suporte ao padrão PKCS#6 (descontinuado). Escolha [0] descontinuada.
ExtendedCertificatesAndCertificates ::=   [SET OF] [SEQUENCE OF] ExtendedCertificateOrCertificate	Tipo definido para o transporte autenticado de um conjunto de CRLs, como conteúdo de uma mensagem assinada. Pretende-se que possa conter cadeias de certificação, mas com o significado de "cadeia" fora do escopo desta definição.
IssuerAndSerialNumber ::= SEQUENCE {   issuer Name,   serialNumber CertificateSerialNumber }	Tipo contendo dados necessários para identificar univocamente um certificado.
KeyEncryptionAlgorithmIdentifier ::=   AlgorithmIdentifier	Tipo definido para identificar um algoritmo de cifragem capaz de operar sobre cadeias de octetos que representam chaves de cifra, em modo de encriptação ou decriptação, sob o controle de uma chave de cifra. O contexto determina qual das operações é pretendida (ex: rsaEncription)
Version ::= INTEGER	Tipo definido para identificar a versão do padrão PKCS#7 utilizada, para permitir compatibilidade com versões futuras.

.
C2-4.2.3- Sintaxe Geral

A sintaxe geral do padrão PKCS#7 dá suporte a seis tipos de dados submetíveis a funções criptográficas (content types),  e, na versão 1.6, também à inclusão de tipos privados, representados através de identificadores de objetos (OID). Esses seis tipos pré-definidos são: data, signed data, enveloped data, signed-and-enveloped data, digested data, e encrypted data. Na versão 1.5 o padrão exporta um tipo, ContentInfo, além dos identificadores de objeto (OIDs). Na versão 1.6 o padrão exporta qualquer símbolo.

Há duas classes de tipo de dados nesse padrão. A primeira, chamada classe base, contém os tipos que representam "apenas dados". A segunda, chamada classe agregadora (enhanced), contém tipos que representam dados processados por funções criptográficas. Na classe base inclui-se por enquanto apenas o tipo data. (data content type), e na classe agregadora os outros cinco tipos pré-definidos, descritos acima.

A agregação de criptografia à representação de um dado encapsula o tipo desse dado. Assim, devido à recursividade, podemos também classificar conteúdos como interno (o dado que se submete à função criptográfica) ou externo ao ecapsulamento (o dado que a agragação criptográfica produz).

O padrão foi projetado com o propósito de que a agregação criptográfica possa ser produzida em um único passo sobre a representação BER do conteúdo interno (de tamanho possivelmente indefinido), resultando na representação BER do conteúdo externo do tipo agregado. Entretanto, este propósito pode ser inviablizado quando o tipo agregado requer codificação DER (como requerem os tipos signed-data, signed-and-enveloped data, e digested-
data) , requerendo do codificador um passo extra de codificação, restringindo-se o primeiro passo ao cálculo do comprimento da representação. (ver a sessão 2 em [7] v1.6 a respeito).

A sintaxe geral para transmissão de conteúdo representado com agregação criptográfica conforme o padrão PKCS#7 (content) requer o tipo e ASN.1

ContentInfo:

ContentInfo ::=  SEQUENCE
{
     contentType ContentType,
     content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL
}

ContentType ::=  OBJECT IDENTIFIER

Os campos no tipo ContentInfo tem a seguinte semântica:
 

• contentType indica o tipo do conteúdo. Trata-se de um identificador de objeto (OID) constituida por uma sequência de inteiros designados pela autoridade responsável pela difinição do tipo. Esse identificador de tipo pode ser o de um dos seis tipos pre-definidos pelo padrão PKCS#7, descritos adiante: data, signedData, envelopedData, signedAndEnvelopedData, digestedData, and encryptedData.
• content é o conteúdo. O campo é opcional, e se não estiver presente, seu valor deve ser fornecido por outros meios. Seu tipo é definido na estrutura de encapsulamento do tipo identificado em contentType.


Restrições a opcionalidades e encapsulamento nessa sintaxe geral são discutidos na sessão 7 em [7] v1.5.
 
 

C2-4.3.1 Data content type

Data ::= OCTET STRING

Semântica:  A cadeia de octetos pretende representar qualquer conteúdo, cuja interpretação é de encargo da aplicação. Pode representar, por exemplo, tanto um arquivo de texto em ASCII como a codificação DER de algum objeto conhecido da aplicação.

C2-4.3.2 Signed-data content type

SignedData ::= SEQUENCE
{
     version Version,
     digestAlgorithms DigestAlgorithmIdentifiers,
     contentInfo ContentInfo,
     certificates [0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL,
     crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
     signerInfos SignerInfos
}

DigestAlgorithmIdentifiers ::=

     [SET OF] [SEQUENCE OF] DigestAlgorithmIdentifier

SignerInfos ::= [SET OF] [SEQUENCE OF] SignerInfo

SignerInfo ::= SEQUENCE
{     version Version,
      issuerAndSerialNumber IssuerAndSerialNumber,
      digestAlgorithm DigestAlgorithmIdentifier,
      authenticatedAttributes [0] IMPLICIT Attributes OPTIONAL,
      digestEncryptionAlgorithm DigestEncryptionAlgorithmIdentifier,
      encryptedDigest EncryptedDigest,
      unauthenticatedAttributes [1] IMPLICIT Attributes OPTIONAL
}

EncryptedDigest ::= OCTET STRING

A semântica dos campos do tipo SignedData é a seguinte:
 

• version é número de versão da sintaxe. Deve ser 1 para esta versão do padrão PKCS#7
• digestAlgorithms é uma coleção (lista) de identificadores de algoritmos de hash usado pelos signatários, que pode ser vazia. O processo de cálculo de hash (digest) é discutido na sessão 9.3 em [7]v1.5
• contentInfo é o conteúdo a ser assinado
• certificates é um conjunto [lista] de certificados PKCS #6 extended ou X.509. Pretende-se suficiente para conter cadeias de certificação completas, incluido certificados auto-assinados na raiz da cadeia, mas que pode também conter certificados a mais ou a menos que o necessário para a formação de uma tal cadeia. Para este caso supõe-se que a aplicação esteja capacitada a costruir a cadeia de certificação a partir do certificado de entidade final, acessando outros meios.
• crls é um conjunto [lista] de CRLs. Pretende-se suficiente para permitir à aplicação determinar se os certificados no campo anterior estão ou não com status de validade, mas que pode também conter crls a mais ou a menos que o necessário para tais validações.
• signerInfos é um conjunto [lista] de campos onde cada campo contém informação sobre um dos signatários do conteúdo. A lista pode ser vazia. Cada campo signerInfo contém os seguintes campos:
• version  é número de versão da sintaxe. Deve ser 1 para esta versão do padrão PKCS#7
• issuerAndSerialNumber especifica o certificado de chave pública que verifica a assinatura do signatário sobre o conteúdo.
•  digestAlgorithm especifica o algoritmo de hash usado na assinatura do signatário sobre o conteúdo. Deve constar da lista homônima na estrutura superior, descrita acima.
• authenticatedAttributes é um conjunto de atributos que são autenticados pela assinatura deste signatário. Este campo é opcional, mas deve estar presente se o tipo do conteúdo descrito em ContentInfo não for data. Se presente, deve conter pelo menos dois atributos.
1. Um atributo PKCS #9 de tipo descritor-de-tipo tendo como valor o descritor do tipo de conteúdo em ContentInfo sendo autenticado pelo signatário.
2. Um atributo PKCS #9 de tipo message-digest tendo como valor o hash do referido conteúdo.  Outros atributos úteis, como selo temporal da lavratura da autenticação, são também descritos em PKCS #9.

Detalhes de implementação e interpretação são discutidos na sessão 9 em [7]v1.5

C2-4.3.2.1 - Processo de cálculo de digesto da mensagem (message digest process)

O processo de cálculo do digesto da mensagem (message-digesting process) calcula o digesto ou sobre o conteúdo, ou sobre esse conteúdo junto aos atributos autenticados do signatário. Em qualquer dos casos, a entrada inicial do processo é o "valor" do conteúdo a ser assinado. Especificamente, a sequência de octetos da codificação DER do valor do campo ContentInfo que vai ser submetido à lavra de assinatura  (os octetos que representam o identificador e o comprimento do objeto não são incluídos)

A saída desse processo, chamado digesto da mensagem, depende da presença ou não do campo authenticatedAttributes. Quando o campo está ausente, o resultado é justamente o digesto do conteúdo. Quando o campo está presente, entretanto, a saída é o digesto completo da codificação DER do valor de Attributes contido no campo authenticatedAttributes. (para esclarecimento: o encapsulamento DER correspondente ao tag IMPLICIT [0] no campo authenticatedAttributes não é parte do valor de Attributes. O rótulo do valor de Attributes é SET OF, e a codificação DER da tag SET OF, ao invés da codificação da tag IMPLICIT [0], é para ser "hasheada" junto com a codificação do comprimento e do valor de Attributes) . Como o valor de Attributes, quando o campo está presente, deve conter como atributos o tipo de conteúdo e o digesto do conteúdo, esses valores são assim indiretamente incluídos na saída do processo.

Quando o contéudo sendo assinado é tipado (tipo estruturado, distinto de data) e o campo authenticatedAttributes está ausente, só o valor do conteúdo é hasheado. Este métido tem a vantagem de que o comprimento do conteúdo não precisa ser conhecido de antemão, e é compatível com o padrão PEM.

Embora os octetos do identificador e os do comprimento não são incluídos no hash, eles ainda são protegidos por outros meios. O comprimento é protegido pela probabilidade baixíssima de colisão entre o valor de hash calculado, e o valor de hash que corresponderá a um novo conteúdo, em caso de adulteração do conteúdo ou reuso ao longo do transporte. Além disso, assumindo que o tipo do conteúdo determina univocamente os octetos que codificam o identificador desse tipo, esses octetos estarão implicitamente protegidos de uma das duas maneiras seguintes. Ou pela inclusão do tipo entre os atributos autenticados, ou pelo uso da alternativa compatível com o padrão PEM, (4.3.2.2), o que implica ser o tipo deste conteúdo não estruturado (data)

Nota: O fato de que o digesto é calculado sobre uma parte de uma codificação DER, não implica que a codificação DER seja o método requerido para codificar o que será transportado. De fato, supõe-se que algumas implementações usarão outras codificações distintas do DER para transporte, mas essa prática não afeta o processo de cálculo do valor de hash.

C2-4.3.2.2 - Processo de cifragem de valor de hash (Digest-encryption process)

A entrada para o processo de cifragem de digesto -- o valor de entrada para o algoritmo de cifragem do signatário, inclui o resultado do processo de cálculo de digesto e o identificador do objeto algoritmo de cifragem. O resultado será a cifragem da codificação BER de um valor de tipo DigestInfo, com a chave privada do signatário.

DigestInfo ::= SEQUENCE
{    digestAlgorithm DigestAlgorithmIdentifier,
     digest Digest
}

Digest ::= OCTET STRING

digestAlgorithm identifica o algoritmo empregado no processo 4.3.2, (deve ser o mesmo valor do campo equivalente em SignerInfo), e digest é o resultado de 4.3.2. [7]v1.5 contém comentários adicionais sobre detalhes dessas estruturas em relação a potenciais ataques decorrente de ambiguidades, e temas relacionados à compatibilidade com o padrão PEM.

C2-4.3.3 Enveloped-data content type

O tipo Enveloped-data content consiste de uma estrutura de dados contendo dados encriptados de qualquer tipo compatível com esse padrão, e a correspondente chave de decifragem cifrada para um ou mais destinatários. A combinação de conteúdo encriptado e chave de cifra encriptada para um destinatário é chamado "envelope digital", a ele endereçado. Qualquer tipo de dado compatível com esse padrão pode ser envelopado para um número qualquer de destinatários, em paralelo.

O processo pelo qual um envelope digital é formado envolve os seguintes passos.

1. Uma chave de encriptação de conteúdo para um algoritmo em particular é gerado aleatoriamente (chave de sessão).
2. Para cada destinatário, a chave de sessão (content-encryption key) é encriptada com a chave pública do destinatário.
3. Para cada destinatário, o criptograma da chave de sessão resultante do passo 2 é juntado a informações adicionais sobre o destinatário (conforme tipo RecipientInfo, definido abaixo).
4. O conteúdo é encriptado com a chave de sessão, o que pode requerer  acolchoamento, se o algoritmo que encripta esse conteúdo for uma cifra de bloco (detalhes abaixo).
5. os respectivos valore RecipientInfo são juntados ao criptograma do conteúdo, conforme tipo EnvelopedData, descrito abaixo.

Tipos

EnvelopedData ::= SEQUENCE
{   version Version,
    recipientInfos RecipientInfos,
    encryptedContentInfo EncryptedContentInfo
}

RecipientInfos ::= SET OF RecipientInfo

EncryptedContentInfo ::= SEQUENCE
{   contentType ContentType,
    contentEncryptionAlgorithm
    ContentEncryptionAlgorithmIdentifier,
    encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL
}

EncryptedContent ::= OCTET STRING

RecipientInfo ::= SEQUENCE
{    version Version,
     issuerAndSerialNumber IssuerAndSerialNumber,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     encryptedKey EncryptedKey
}

EncryptedKey ::= OCTET STRING

Observações
 

• receipientInfos deve conter conter pelo menos um elemento.
• issuerAndSerialNumber especifica o certificado do destinatário usado para cifrar-lhe a sua chave de sessão
• Para compatibilidade com o padrão PEM, o método de encriptação do conteúdo especifica que a cifragem será sobre a sequência de octetos que constitui a codificação BER de comprimento definido do campo content do valor ContentInfo ao qual a envelopagem é aplicada, excluídos os valores do identificador de tipo e do comprimento. A vantagem é que o comprimento não precisa ser conhecido de antemão à cifragem do conteúdo.

O compirmento pode ser protegido por preservação na encritpação, dependendo do algoritmo de cifra. O valor do identificador não é protegido, mas pode, sob determinadas condições, ser recuperado do tipo de conteúdo, como explicado na sessão 4.3.2.1. Proteção explícita para os valores do identificador e comprimento requerem o emprego do tipo signed-and-enveloped-data content, ou que o conteúdo seja tipado com os tipos digested-data e enveloped-data, nessa ordem.
• A razão porque é requerida a codificação BER de comprimento definido é a seguinte: o bit BER que indica se o comprimento do dado é ou não de antemão conhecido, não será gravado em nunhuma parte do envelope (não faz parte do descritor de tipo do conteúdo).
• Alguns algoritmos de cifra assumem que o conteúdo tem comprimento em octetos múltiplo de k > 1 (cifra de bloco). Neste caso a aplicação deve fornecer o método para acomodar conteúdo de comprimento não múltiplo de k. A acomodação deve ser a des, no último bloco de cifra, completar os octetos faltantes com um inteiro que representa o número de octetos faltantes, ou k, caso contrário. Isto é, o acolchoamento deve ser (para k menor ou igual a 255)

01 (se 1 falta 1 octeto)
02 02 (se faltam 2 octedos)
...
k k ... k (k vezes, se 0 não faltam octetos)
• O algoritmo de cifragem da chave de sessão recebe apenas o valor dessa chave.

C2-4.3.4 Signed-and-enveloped-data content type

O tipo Signed-and-enveloped-data content consiste de uma estrutura de dados contendo dados encriptados de qualquer tipo compatível com esse padrão, a correspondente chave de decifragem e o autenticador da conteúdo encriptado, produzido pela cifragem do hash do conteúdo com a chave privada do remetente, estes cifrados para um ou mais destinatários.

O processo pelo qual um envelope digital com conteúdo assinado é formado envolve os seguintes passos.

1. Uma chave de encriptação de conteúdo para um algoritmo em particular é gerado aleatoriamente (chave de sessão).como em 4.3.3
2. Para cada destinatário, a chave de sessão (content-encryption key) é encriptada com a chave pública do destinatário. .como em 4.3.3
3. Para cada destinatário, o criptograma da chave de sessão resultante do passo 2 é juntado a informações adicionais sobre o destinatário (conforme tipo RecipientInfo, definido abaixo).
4. Para cada signatário, o digesto da mensagem é calculado com um algoritmo específico de escolha do signatário. (se dois signatários usarem o mesmo algoritmo, o digesto de ambos é calculado apenas uma vez) .como em 4.3.3
5. Para cada signatário, o digesto da mensagem é juntado a informações sobre o processo de digesto, para serem cifrados com a chave privada do signatário, e o resultado cifrado com a chave de sessão (content-encription key), incluindo acolchamento, se necessário (ver detalhes acima).
6. Para cada signatário, o resultado do passo anterior é juntado a informações específicas sobre o processo de lavra da assinatura, para produzir seu autenticador do conteúdo em um campo de tipo SignerInfo (descrito em 4.3.1)
7. O conteúdo é encriptado com a chave de sessão, o que pode requerer  acolchoamento, se o algoritmo que encripta esse conteúdo for uma cifra de bloco.
8. os respectivos descritores de algoritmos de hash e os valores SignerInfo para cada signatário, e os valores RecipientInfo, são juntados ao criptograma do conteúdo, conforme tipo SignedAndEnvelopedData, descrito abaixo.

Observações
 

• Um destinatário abre o envelope de conteúdo assinado em dois passos. Primeiro, o correspondente criptograma com a chave de sessão é decriptado com a chave privada do destinatário, e o criptograma do conteúdo é decriptado com a chave de sessão dali obtida. Segundo, a parte correspondente ao digesto do conteúdo no respectivo autenticador é decriptada para cada signatário, usando a chave de sessão obtida no passo anterior, e o resultado decriptado com a chave pública do respectivo signatário, que será comparado com um digesto do conteúdo calculado independentemente, conforme já descrito.
• Esse tipo provê funcionalidade critpográfica similar à combinação sequencial de tipagem por singed-data e enveloped-data. Entretanto, como não contém atributos autenticados e inautenticados, nem provê a envelopagem de informação adicional sobre a lavra de assinaturas, a combinação sequencial de  singed-data e enveloped-data é geralmente preferível ao tipo SignedAndEnvelopedData, exceto quando se pretende a compatibilidade com o padrão PEM.
• A entrada do processo digest-encryption é a mesma que em 4.3.2.2, mas o processo em si é diferente. Especificamente, o processo envolve dois passos. Primeiro, a entrada é fornecida ao algoritmo de hash do signatário, como em 4.3.2.2. Segundo, o resultado do primeiro passo é encriptado com a chave de sessão. Não há codificação DER entre os dois passos. Comentários sobre os motivos em [7]v1.5
• Ocorre compatibilidade com o processo de tipagem ENCRYPTED do padrão PEM quando o tipo de conteúdo é não estruturado (data), o algoritmo de hash é MD2 ou MD5, o algoritmo de cifra de conteúdo é DES em modo CBC, o algoritmo de cifragem de digesto é rsaAlgorithm (definido em PKCS#1 e no módulo 2). Sob tais condições, a compatibilidade decorre pelos mesmos motivos levantados ns sessão 9.5 de [7]v1.5.

SignedAndEnvelopedData ::= SEQUENCE
{   version Version,
    recipientInfos RecipientInfos,
    digestAlgorithms DigestAlgorithmIdentifiers,
    encryptedContentInfo EncryptedContentInfo,
    certificates [0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL,
    crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
    signerInfos SignerInfos
}

C2-4.3.5 Digested-data e Encrypted data content type

DigestedData ::= SEQUENCE
{   version Version,
    digestAlgorithm DigestAlgorithmIdentifier,
    contentInfo ContentInfo,
    digest Digest
}

Digest ::= OCTET STRING

EncryptedData ::= SEQUENCE
{
    version Version,
    encryptedContentInfo EncryptedContentInfo
}

Os campos desses tipos já foram aqui descritos.

C2-4.3.6 Object Identifiers

O identificador pkcs-7 identifica esse padrão.

pkcs-7 OBJECT IDENTIFIER ::=
{    iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 7
}

Os identificadores de objeto data, signedData, envelopedData,
signedAndEnvelopedData, digestedData, and encryptedData,
identificam, respectivamente, os tipo de conteúdo data,  signed-data, enveloped-data, signed-and-enveloped-data, digested-data, e encrypted-data aqui descritos.

data OBJECT IDENTIFIER ::=                   { pkcs-7 1 }
signedData OBJECT IDENTIFIER ::=             { pkcs-7 2 }
envelopedData OBJECT IDENTIFIER ::=          { pkcs-7 3 }
signedAndEnvelopedData OBJECT IDENTIFIER ::= { pkcs-7 4 }
digestedData OBJECT IDENTIFIER ::=           { pkcs-7 5 }
encryptedData OBJECT IDENTIFIER ::=          { pkcs-7 6 }

Esses identificadores foram registrados com o propósito de serem usados no campo contentType de um valor do ContentInfo. O campo content daquele tipo, definido com a sintaxe ASN.1 ANY DEFINED BY contentType, teria assim tipo ASN.1, respectivamente, Data, SignedData, EnvelopedData, SignedAndEnvelopedData, DigestedData, e EncryptedData. Também foram registrados com o propósito de serem usados em atributos content-type descritos no padrão PKCS #9.

.

Aula 8

A versão atual do padrão PKCS#12 segue sendo a primeira, a versão 1.0, publicada em 24 de junho de 1999. O padrão descreve sintaxes de transferência para o transporte de informação pessoal para identificação, incluindo chaves privadas, certificados, CRLs, e uma miscelânea de extensões e segredos compartilhados. Sistemas e aplicações que dão suporte a este padrão permitirão a usuários importar, exportar e exercer sua identidade através de uma estrutura de dados que compõe uma unidade de informação pessoal.

O transporte assim habilitado permite a transferência de informação pessoal sob váriios modos de privacidade e integridade, inclusive para implementação em hardware, tais como smart cards e tokens PCMCIA. Este padrão pode ser visto como uma extensão ao PKCS#8, pela inclusão de informações essenciais de identificação e pelo estabelecimento de padrões de integridade.
 

C2-4.5.1- Notação

Os seguintes termos são empregados nos documentos que definem o padrão PKCS#12, em adição aos já definidos acima e em módulos anteriores.
 

Notação para o PKCS#12

Termo	Definição
Destination platform:	Plataforma de destino: Alvo final da transferência de uma unidade de dados contendo informação pessoal identificadora, através de um protocolo,  independentemente da comunicação para a transferência através do protocolo ser ou não bidirecional. Esta unidade se chama PDU (Protocol Data Unit)
Encryption Key Pair.	(DestEncK): Um par de chaves assimétircas (pública/privada) para cifragem, no modo  chave pública deste padrão. A parte púbica é chamada PDestEncK (TPDestEncK quando se deseja enfatizar que a chave pública é "confiável"), e a parte privada é chamada VDeskEncK.
Export time:	Tempo de exportação: Selo temporal correspondente ao momento em que um usuário lê informações pessoais de uma plataforma de origem e a encapsula em uma PDU.
Import time:	Tempo de imprtação:  Selo temporal correspondente ao momento em que um usuário lê informações pessoais de uma PDU e a desencapsula, para amrazenamento ou uso em uma  plataforma de destino.
PFX:	PFX: o formato final de PDU para transporte, definido neste padrão.
Platform:	Plataforma computacional: Combinação de máquina, sistema operacional e softwares aplicativos na qual o usuário exercita uma identidade pessoal.  Uma aplicação nesse contexto é software que faz uso desta identidade. EM sistemas multiusuários, considera-se uma plataforma, ao menos, para cada usuário.
PDU:	Protocol Data Unit (PDU): Sequência de bits em formato independente de máquina constituindo uma mensagem em um protocolo.
Signature Key Pair:	Signature Key Pair (SrcSigK): Um par de chaves assimétricas (privada/pública) para assinatura, específico para uma plataforma, usado no modo chave pública deste padrão. A parte púbica é chamada PSrcSigK (TPSrcSigK quando se deseja enfatizar que a chave pública é "confiável"), e a parte privada é chamada VSrcSigK.
Source Platform:	Plataforma de origem: Origem da transferência de uma unidade de dados contendo informação pessoal identificadora (PDU), independentemente da comunicação para a transferência ser ou não bidirecional.

.
C2-4.5.2- Preliminares

Modos de transporte (mode choice policies)

Há quatro combinações de modos de privacidade e integridade. Dois modos de privacidade usam encriptação para proteger as informações pessoais em um PDU contra vazamento no transporte, e dois modos de integridade protegem-nas contra adulteração.

Os modos de privacidade são

• Public-key privacy mode: PDU é envelopado na plataforma de origem com cifragem pela chave pública de uma plataforma de destino conhecida.
• Password privacy mode: PDU é envelopado na plataforma de origem com cifragem por chave simétrica derivada de um par nome-senha, conforme padrões descritos em PKCS#5. Se o modo de integridade for também derivado de senha, esta pode ou não ser a mesma empregada no modo privacidade.


Os modos de integridade são

• Public-key privacy mode: PDU é digitalmente assinado na plataforma de origem com cifragem pela chave privada da plataforma de origem  (normalmente distinta da chave privada possivelmente transportada).

Password privacy mode: MAC do PDU calculado na plataforma de origem com algoritmo de hash, uma senha de integridade, um valor de salt e um contador. Se o modo de privacidade for também derivado de senha, esta pode ou não ser a mesma empregada no modo privacidade.


Chaves públicas "confiáveis"

Além dos modos de proteção descritos acima, o transporte iclui também o status de confiança da chave pública contida em PDUs, em relação à plataforma de origem. Em modo public-key privacy, a chave que cifra a PDU é normalmente distinta das chaves privadas transportadas, e em modo public-key integritiy, a chave que verifica a assinatura é normalmente distinta das chaves públicas transportadas. A chave pública que fecha o envelope de uma PDU em modo public-key privacy é chamada TPDestEncK (confiável), por supor-se que identifica a plataforma de destino do PDU.  A chave pública que verifica a assinatura de uma PDU em modo public-key integrity é chamada TPSrcSigK (confiável), por supor-se que identifica a plataforma de origem do PDU.

C2-4.5.3- Sintaxe Geral

Cada plataforma aderente ao padrão deve ser capza de importar e exportar AuthenticatedSafes envelopados em PDUs PFX. Um AuthenticatedSafe é agregado ou com a assinatura ou com o MAC da plataforma de origem para produzir uma PDU PFX. Os que são assinados, também agregam a chave de verificação TPSrcSigK. Um AuthenticatedSafe é uma sequência de valores ContentInfo. Alguns desses valoes podem ser não estruturados (data), e outros devem ser ou EnvelopedData (public-key privacy mode) ou EncryptedData (password privacy mode)

Cada valor ContentInfo contém uma coleção arbitrária de chaves privadas, chaves privadas cifradas no padrão PKCS#8, certificados, CRLs ou objetos opacos (de estrutura desconhecida deste padrão), representados em valores do tipo SafeContents. A razão para os modos não encriptados de transporte se deve a restrições governamentais ao uso de criptografia, que podem viger no percurso do transporte ou nas direitos de licenciamento de um software de aplicação.

A envelopagem final do AuthenticatedSafe para formar um PDU PFX é uma assinatura ou MAC, para autenticar conteúdo possivelmente cifrado com criptografia assimétrica. Essa ordem contraria a recomendação geral para protocolos que usam criptografia assimétrica baseada em exponenciação modular. Porém, as circusntâncias que caracterizam objetivos do protocolo a justificar tal recomendação não se aplicam ao PKCS#12, sendo preferível, no caso em tela, autenticar todo o conteúdo transportado, inclusive os que não estejam assimetricamente encriptados.

C2-4.5.4- Sintaxe do formato PFX

Este formato corresponde ao modelo de dados apresentado acima, e faz uso frequente de tipos definidos no PKCS  #7 (4.1 - 4.3). O formato contem

1. Inidicador de versão, que deve ser v3 para a versão deste documento..
2. Um valor ContentInfo como definido no PKCS #7, cujo contentType será signedData no modo public-key integrity, ou data no modo password integrity.
3. Uma instância opcional de MacData, presente apenas em modo password integrity. Se presente, o objeto deve conter um valor DigestInfo como definido em PKCS #7, contendo um valor MAC, o valor em macSalt e um valor iterationCount. (veja apendice B de PKCS#12 [8], para mais detalhes) o valor da chave de MAC é derivado da senha (que não deve ser transportada no PFX), do macSalt e do interationCount, conforme descrito na sessão seguinte. O MAC é derivado do valor em authSafe e da chave de MAC via HMAC, conforme descrito em no. RFC 2104: (Keyed-Hashing for Message Authentication. IETF, February 1997).


PFX ::= SEQUENCE
{     version INTEGER {v3(3)}(v3,...),
      authSafe ContentInfo,
      macData MacData OPTIONAL
}

MacData ::= SEQUENCE
{     mac DigestInfo,
      macSalt OCTET STRING,
      iterations INTEGER DEFAULT 1
   -- Note: The default is for historical reasons and its use is deprecated.
   -- A higher value, like 1024, is recommended.
}
 

4.6.1 AuthenticatedSafe type

Como mencionado, o campo contentType de authSafe deve ser do tipo Data ou SignedData. Deve conter, direta (Data) ou indiretamente (SignedData), o valor da codificação BER de um dado do tipo AuthenticatedSafe.

AuthenticatedSafe ::= SEQUENCE OF ContentInfo
-- Data if unencrypted
-- EncryptedData if password-encrypted
-- EnvelopedData if public key-encrypted

O campo content dos valores ContentInfo dessa sequência contém ou dado literal (Data), ou dado encriptado ou dado envelopado. No dois últimos casos, o dado será o a codificação BER de uma instância de SafeContents. A sessão 4.7 explica em mais detalhes a construção de valores do tipo AutenticatedSafe.
 

4.6.2 SafeBag type

O tipo SafeContents é constituido de valores do tipo SafeBag, que contém uma unidade de informação: uma chave, certificado, etc, identificado por um OID. Note que a especificação abaixo usa a versão 93 da ASN.1

SafeContents ::= SEQUENCE OF SafeBag

SafeBag ::= SEQUENCE
{
      bagId BAG-TYPE.&id ({PKCS12BagSet})
      bagValue [0] EXPLICIT BAG-TYPE.&Type({PKCS12BagSet}{@bagId}),
      bagAttributes SET OF PKCS12Attribute OPTIONAL
}
PKCS12Attribute ::= SEQUENCE
{     attrId ATTRIBUTE.&id ({PKCS12AttrSet}),
      attrValues SET OF ATTRIBUTE.&Type ({PKCS12AttrSet}{@attrId})
} -- This type is compatible with the X.500 type ’Attribute’

PKCS12AttrSet ATTRIBUTE ::=
{
     friendlyName | -- from PKCS #9
     localKeyId, -- from PKCS #9
     ... -- Other attributes are allowed
}

O campo opcional bagAttributes permite à fonte desingar apelidos e identificadores para chaves, etc, permitindo a ferramentas de visualização mostrar strings significativas para algum tipo de usuário. Seis tipos de "sacolas de segurança" (safe bags) são definidos neste padrão

bagtypes OBJECT IDENTIFIER ::=  {pkcs-12 10 1}
BAG-TYPE ::=                    TYPE-IDENTIFIER
keyBag BAG-TYPE ::=             {KeyBag IDENTIFIED BY {bagtypes 1}}
pkcs8ShroudedKeyBag BAG-TYPE::= {PKCS8ShroudedKeyBag IDENTIFIED BY {bagtypes 2}}
certBag BAG-TYPE ::=            {CertBag IDENTIFIED BY {bagtypes 3}}
crlBag BAG-TYPE ::=             {CRLBag IDENTIFIED BY {bagtypes 4}}
secretBag BAG-TYPE ::=          {SecretBag IDENTIFIED BY {bagtypes 5}}
safeContentsBag BAG-TYPE ::=    {SafeContents IDENTIFIED BY {bagtypes 6}}
PKCS12BagSet BAG-TYPE ::=
{      keyBag |
       pkcs8ShroudedKeyBag |
       certBag |
       crlBag |
       secretBag |
       safeContentsBag,
       ... -- For future extensions
}

Na medida em que novas sacolas venham a ser reconhecidas em futuras versões deste padrão, o tipo PKCS12BagSet pode ser extendido.

4.6.2.1 KeyBag type

O tipo KeyBag é o tipo PrivateKeyInfo do padrão PKCS #8. Note que uma keyBag contém apenas uma chave privada.

KeyBag ::= PrivateKeyInfo

4.6.2.2 PKCS-8ShroudedKeyBag type

Um valor PKCS8ShroudedKeyBag contém uma chave privada que foi encriptada de acordo com o padrão PKCS #8. ("embrulhada por" PKCS#8) Note que um  pkcs8ShroudedKeyBag contém apenas uma chave privada encriptada.

PKCS8ShroudedKeyBag ::= EncryptedPrivateKeyInfo

4.6.2.3 CertBag type

Um valor CertBag contém um certificado digital de algum tipo. OIDs são usados para distinguir diferentes tipos de certificado.

CertBag ::= SEQUENCE
{     certId BAG-TYPE.&id ({CertTypes}),
      certValue [0] EXPLICIT BAG-TYPE.&Type ({CertTypes}{@certId})
}

x509Certificate BAG-TYPE ::= {OCTET STRING IDENTIFIED BY {certTypes 1}}
-- DER-encoded X.509 certificate stored in OCTET STRING

sdsiCertificate BAG-TYPE ::= {IA5String IDENTIFIED BY {certTypes 2}}
-- Base64-encoded SDSI certificate stored in IA5String

CertTypes BAG-TYPE ::=
{     x509Certificate |
      sdsiCertificate,
      ... -- For future extensions
}

4.6.2.4 CRLBag type

Um valor CRLBag contém uma lista de revogação de certificados de algum tipo. OIDs são usados para distinguir diferentes tipos de CRLs.

CRLBag ::= SEQUENCE
{     crlId BAG-TYPE.&id ({CRLTypes}),
      crlValue [0] EXPLICIT BAG-TYPE.&Type ({CRLTypes}{@crlId})
}

x509CRL BAG-TYPE ::= {OCTET STRING IDENTIFIED BY {certTypes 1}
-- DER-encoded X.509 CRL stored in OCTET STRING

CRLTypes BAG-TYPE ::=
{     x509CRL,
      ... -- For future extensions
}

4.6.2.5 The SecretBag type

Cada segredo pessoal que a fonte queira introduzir no PDU estará em uma instância distinta de tipo SecretBag, que contém um objeto identificável por OID.

SecretBag ::= SEQUENCE
{     secretTypeId BAG-TYPE.&id ({SecretTypes}),
      secretValue [0] EXPLICIT BAG-TYPE.&Type ({SecretTypes}{secretTypeId})
}

SecretTypes BAG-TYPE ::=
{
      ... -- For future extensions
}

Cada implementador pode acrescentar elementos de sua escolha nesse conjunto.

4.6.2.6 SafeContents type

O sexto tipo de sacola que pode ser carregada em um valor SafeBag é o tipo SafeContents. Sua estrutura recursiva permite aninhamento arbitrário de múltiplos KeyBags, PKCS8ShroudedKeyBags, CertBags, CRLBags and SecretBags within the top-level SafeContents.

4.6.3 Usando PFX

Esta sessão descreve como criar e usar PDUs em formato PFX

4.6.3.1 Criando PDUs PFX
 

1. Da linguagem ASN.1 fica claro como criar um número qualquer de instâncias de SafeContents, cada um contendo um número de isntâncias de SafeBags, possivelmente aninhadas. Chamemos as instâncias SafeContents SC1, SC2,..., SCn
2. Para cada SCi, dependendo da opção de encriptação:
a) Se SCi não foi tipado com encriptação, crie a instância CIi de tipo ContentInfo com o campo contentType contendo o tipo Data. O conteúdo do campo OCTET STRING de Data deve ser a codificação BER completa de SCi (incluindo os octetos de tag, comprimento e valor).
b)  Se SCi foi tipado com encriptação por senha, crie a instância CIi de tipo ContentInfo com o campo contentType contendo o tipo EncryptedData. O conteúdo do campo encryptedContentInfo deve ser o criptograma da codificação BER completa de SCi (os octetos de tag e comprimento incluídos na cifragem).
c)  Se SCi foi tipado com encriptação pela chave pública da plataforma de destino, crie a instância CIi de tipo ContentInfo com o campo contentType contendo o tipo EnvelopedData., procedendo em seguida da mesma forma que em b)
3. Crie uma isntância de AuthenticatedSafe sequenciando os CIs com o correspondente construtor ASN.1,
4. Crie um objeto ContentInfo T com o campo contentType contendo o tipo Data. O conteúdo do campo OCTET STRING de Data deve ser a codificação BER completa de T (incluindo os octetos de tag, comprimento e valor).
5. Para proteção quanto à integridade,
a)  Se o PDU PFX é para ser autenticado com assinatura digital, construa um objeto ContentInfo C contendo em seu campo contentType o tipo SignedData., e com o campo contentInfo do dado assinado contendo T. C é o contentInfo no primeiro nível da estrutura de dados do formato PFX.
b)  Se o PDU PFX é para ser autenticado com HMAC, compute um HMAC do conteúdo de Data em T, usando o algoritmo SHA-1 (isto é, excluindo os octetos da tag e do comprimento do objeto BER)  Este digesto é o mesmo que seria produzido intermediariamente no passo a).
.
4.6.3.1 Importando PDUs PFX

A importação de PDUs PFX é obtida revertendo-se a ordem dos passos, substituindo-se a lavra pela verificação de autenticadores (assinatura ou MAC), e encriptação por decriptação. O importador deve ignorar OIDs desconhecidos, talvez com o cuidado de alertar o usuário sobre sua presença no PFX.

Cuidado especial deve ser tomado pela aplicação quando da importação de um item do PFX que irá requerer a sobrescrita de algum item já armazenado. O comportamento da aplicação deve depender, neste caso, do tipo de item (ex: CRLs e chaves privadas).

Bibliografia

Material de referência

Texto de Referência

· Housley, R. & Polk, T.: "Planning for PKI" ,
 John Willey & Sons, 2001, New York

· Rezende, P.: "Curso C2 - ICP"  (módulos 1 a 6),

Os textos abaixo aprofundam o material abordado no curso.

• [1] Autor anônimo?,  "ASN-1, DER e BER", Univ. Federal do Rio de Janeiro - .pdf - 37 pag
• [2] Curso pós em Redes de computadores - UFRGS:  "O uso de ASN.1 para especificação formal de protocolos", Univ. Federal do Rio Grande do Sul - .pdf - 16 pag
• [3] ITU-T X.208 "ASN-1 Specification", Melbourne, 1988 - pdf - 74 pag.

      ITU-T X.209 "BER for ASN-1 Specification", Melbourne, 1988, 1993 - pdf - 26 pag.
(Obs: A especificação ASN.1 do tipo OBJECT IDENTIFIER está no documento do padrão ITU X.680)
• [4] “RSA Security Inc. Public-Key Cryptography Standards (PKCS)”: PKCS#1 v2.1
• [5] “RSA Security Inc. Public-Key Cryptography Standards (PKCS)”: PKCS#8
• [6] "Internet X.509 Public Key Infrastructure, Certicicate and CRL Profiles" RFC 3280 - txt - 129 pag
• [7] “RSA Security Inc. Public-Key Cryptography Standards (PKCS)”: PKCS#7 v1.5 e v1.6
• [8] “RSA Security Inc. Public-Key Cryptography Standards (PKCS)”: PKCS#12