A Linux Foundation, BastionZero e Docker apresentaram um novo projeto aberto chamado OpenPubKey, que desenvolve o protocolo criptográfico homônimo para a certificação de assinaturas digitais de objetos variados. A tecnologia foi criada como um projeto conjunto das empresas BastionZero e Docker, com o objetivo de simplificar a certificação de assinaturas digitais de imagens de contêineres Docker, evitando suas substituições e confirmando a construção pelo criador declarado. O projeto será desenvolvido em uma plataforma neutra sob a auspícios da Linux Foundation, o que eliminará a dependência de empresas comerciais individuais e facilitará a colaboração com a participação de terceiros. A implementação de referência do OpenPubKey é escrita na linguagem Go e é distribuída sob a licença Apache 2.0.
As capacidades do OpenPubKey não se limitam apenas a imagens de contêineres, e a tecnologia pode ser aplicada para confirmar a fonte de qualquer recurso, prevenir a substituição de dependências e aumentar a segurança dos canais de disseminação de conjuntos de dados. Por exemplo, a tecnologia é aplicável para certificar compilações de software, mensagens individuais e commits. Os criadores de assinaturas precisam apenas de uma conta em um serviço que suporte OpenID, enquanto os consumidores têm a oportunidade de verificar as assinaturas anexadas e confirmar sua associação com o identificador OpenID declarado.
Quanto à sua finalidade, o OpenPubKey lembra o sistema Sigstore criado pelo Google e anteriormente transferido para a Linux Foundation, mas difere dele por simplificar consideravelmente a implementação, o uso e a manutenção, eliminando os componentes de servidor centralizados responsáveis por manter um registro público que confirma a autenticidade das alterações (transparency log) e garantir a operação das autoridades certificadoras (Certificate Authority).
Em vez de implantar suas próprias entidades certificadoras, o OpenPubKey utiliza autenticação com a tecnologia OpenID e vincula as assinaturas criadas a provedores existentes de OpenID Connect. Em outras palavras, o OpenPubkey permite vincular chaves criptográficas a usuários específicos, usando provedores de OpenID Connect (IdP) em vez de autoridades certificadoras. A tecnologia é totalmente compatível com os provedores de OpenID existentes, como GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak e Google, e não requer alterações do lado deles (é utilizado o token ID padrão fornecido pelo provedor, o que permite implementar o OpenPubKey apenas através de alterações do lado do cliente OpenID Connect).
O token emitido pelo provedor OpenID é transformado em um certificado que vincula criptograficamente o identificador no OpenID Connect à chave pública. Em seguida, o usuário utiliza a chave gerada para assinar quaisquer dados, e essas assinaturas podem ser verificadas posteriormente em relação ao identificador no OpenID Connect. No OpenPubKey, são utilizados chaves efêmeras, cuja duração é limitada — as chaves são geradas no momento do login por meio do OpenID e removidas ao final da sessão com o provedor OpenID.
Algoritmo aproximado para a criação de uma assinatura utilizando o OpenPubKey:
- Login utilizando o provedor OpenID (Google, GitHub, Microsoft, etc.).
- Solicitação do token de identificação ao provedor OpenID.
- Retorno do token, assinado pela chave do provedor e incluindo um campo 'nonce' com dados aleatórios fornecidos na solicitação (é enviado o hash SHA3 da chave pública).
- Uso do token recebido pelo usuário como um certificado, incluindo dados sobre a chave.
- Anexação do token à assinatura, da mesma forma que um certificado.
A verificação consiste em checar se o token anexado foi assinado pelo provedor OpenID e verificar a validade da assinatura digital do recurso com a chave pública, o que permite garantir que o recurso foi assinado usando o identificador do certificado e que isso é confirmado pela assinatura do provedor OpenID. Por exemplo, quem cria a assinatura pode obter um token assinado pelo provedor OpenID Google com informações de que foi verificado como bob@gmail.com e utiliza a chave pública 0x54A5…FF. Ao receber uma mensagem assinada pela mesma chave, o destinatário pode usar o token assinado pelo provedor para verificar que a chave bob@gmail.com — 0x54A5…FF e a mensagem realmente foram assinadas por bob@gmail.com.
A simplificação da arquitetura foi realizada através de certos compromissos (por exemplo, a dependência de provedores OpenID externos e a ausência de um log de alterações com hash hierárquico), que em algumas situações são aceitáveis e em outras não. Para reduzir a dependência dos provedores OpenID, cuja comprometimento ou ações de pessoal podem descreditar o sistema (por exemplo, um provedor invadido pode fornecer uma chave falsa a terceiros), sugere-se o uso de um link adicional, mas não obrigatório, chamado MFA-Cosigner (Multi-Factor Authentication Cosigner) para autenticação multifatorial (o token deve ser assinado não apenas pelo provedor principal, mas também por um serviço de autenticação independente que confirma o usuário).
Entre as fraquezas do OpenPubKey, destaca-se a existência de dados externos que podem ser usados para monitorar a atividade por longos períodos e independentemente de renomeações (o reuso de um token identificador em vez de um novo certificado). A vinculação direta às chaves do OpenID Connect durante a verificação exclui a parte do servidor, mas complica significativamente a implementação do lado do cliente e deixa mais espaço para manobras durante ataques (superfície de ataque) ao cliente, por exemplo, devido ao fato de que a responsabilidade pela rotação de chaves recai sobre o cliente. A falta de um log de alterações não permite que o cliente monitore possíveis vazamentos de chaves.
Fonte: opennet.ru
