Proteja seu sistema IIoT com a biblioteca de criptografia de sua escolha!

Agora, você deve ter lido sobre o OMG Especificação de segurança DDS que aprimora o padrão DDS existente com uma arquitetura e modelo de segurança. A versão 1.0 dessa especificação está prestes a ser finalizada pela OMG. Isso significa que um modelo de segurança centrado em dados agora será nativamente integrado ao padrão DDS - o único padrão de comunicações aberto que foi projetado para fornecer a flexibilidade, confiabilidade e velocidade necessárias para construir aplicações complexas em tempo real, incluindo muitos tipos de IoT industrial sistemas.

Um dos recursos marcantes introduzidos no DDS Security Spec é a noção de uma arquitetura Service Plugin Interface (SPI). O mecanismo de SPIs permite que os usuários customizem o comportamento e as tecnologias que a implementação do DDS usa para Garantia da Informação, sem alterações no código do aplicativo.

Esta postagem do blog explica resumidamente a arquitetura SPI e demonstra uma maneira fácil de aproveitar os plug-ins de segurança integrados RTI Connext DDS Secure para que executem ações criptográficas selecionadas com a biblioteca de criptografia de sua escolha.

DDS Secure Service Plugin Interfaces (SPIs)

A Especificação de Segurança DDS não introduz nenhuma mudança na maneira como os aplicativos interagem com a infraestrutura DDS. Em vez disso, ele define cinco componentes de plug-in diferentes que são aproveitados pela infraestrutura quando necessário. Cada um desses componentes fornece um determinado aspecto da funcionalidade de garantia de informações e tem uma interface padronizada, conforme definido pela Especificação de Segurança DDS. É a isso que se refere o nome Service Plugin Interfaces (SPIs). A arquitetura do plugin é ilustrada na imagem abaixo.

Como você pode ver, existem cinco SPIs que coletivamente fornecem garantia de informações para sistemas DDS. Seus nomes e objetivos são os seguintes:
Nome SPI Objetivo de seus tipos e operações AuthenticationSupport a verificação da identidade de DDS DomainParticipants, incluindo recursos para realizar autenticação mútua e para estabelecer segredos compartilhados.AccessControlTome decisões sobre quais operações protegidas relacionadas ao DDS um DDS DomainParticipant autenticado tem permissão para realizar, incluindo ingressar em um domínio DDS e criar tópicos, DataReaders e DataWriters.CryptographySupport operações criptográficas, incluindo criptografia e descriptografia, hashing, assinaturas digitais e códigos de autenticação de mensagem. LoggingSupport registro de eventos relacionados à segurança para um DDS DomainParticipant. propósitos específicos.

A arquitetura SPI oferece bastante liberdade para personalizar os aspectos de garantia de informações de seu sistema DDS seguro. Todos os aspectos mencionados na lista de marcadores acima podem ser modificados ou reimplementados usando sua própria implementação dos SPIs. O que você não pode mudar é o mecanismo quando a implementação do DDS realmente invoca os métodos dos SPIs - eles apenas são invocados quando necessário. Na verdade, isso é bom porque significa que o middleware continua a se comportar conforme prescrito na especificação e você não precisa se preocupar em quebrar isso.

Além das interfaces dos SPIs, a especificação de segurança DDS também fornece uma descrição funcional dos chamados plug-ins integrados, descritos em detalhes no Capítulo 9 desse documento. Sua intenção principal é fornecer interoperabilidade out-of-the-box entre diferentes implementações de DDS Security. Com o RTI Connext Secure DDS, os plug-ins integrados também são um excelente ponto de partida para personalização.

Personalização dos plug-ins integrados RTI Connext DDS Secure

Os binários do plug-in de segurança integrado fornecidos com o Connext DDS Secure podem ser usados ​​prontos para uso para criar seu sistema DDS que inclui garantia de informações. Tudo que você precisa fazer é configurar corretamente a PropertyQosPolicy de seu DomainParticipant conforme explicado na especificação para apontar para os artefatos de segurança desejados, como controle de acesso e arquivos de configuração de governança, bem como certificados de identidade, entre outros.

Para aqueles que desejam modificar o comportamento dos plug-ins, um conjunto de arquivos de código-fonte compiláveis ​​também é fornecido. No entanto, para muitas situações, os plug-ins Connext DDS Secure oferecem uma opção muito mais fácil. Entre na API OpenSSL EVP ...

Troca de implementações de algoritmo criptográfico

O código-fonte dos plug-ins Connext DDS Secure embutidos usa a biblioteca criptográfica OpenSSL - não por sua funcionalidade SSL ou TLS, mas por seu conjunto de implementações de função criptográfica e uma série de classes auxiliares usadas com aqueles. Se você estiver familiarizado com a programação OpenSSL, saberá que é uma boa prática aproveitar a chamada interface EVP. (Caso você esteja se perguntando sobre isso, como eu:EVP significa EnVeloPe.) Os plug-ins Connext DDS Secure invocam um subconjunto de suas funções, a saber, aquelas relacionadas aos itens na tabela abaixo:
Funcionalidade Algoritmos especificados para plug-ins de segurança DDS integrados Criptografia simétrica e descriptografia AES no modo de contador Galois (GCM) para tamanhos de chave de 128 bits ou 256 bits Assinatura e verificação de algoritmos de assinatura RSA-PSS ou ECDSA com SHA-256 como sua função hashKey exchangeDiffie-Hellman usando aritmética modular (DH) ou curvas elípticas ( ECDH), com parâmetros especificados, códigos de autenticação de mensagem HMAC, com SHA-256 como sua função hash e funções hash GMACSecureSHA-256Geração de número aleatório Qualquer gerador de número aleatório criptograficamente forte

Os plug-ins enviados com o produto usa as implementações OpenSSL dessas funções, conforme encontrado no mecanismo OpenSSL EVP padrão. No entanto, eles também suportam a inserção de seu próprio motor. A implementação do mecanismo OpenSSL pode invocar outras implementações dessas funções criptográficas, por exemplo, aproveitando a biblioteca criptográfica de sua escolha, talvez porque você precise usar implementações compatíveis com FIPS. Algumas bibliotecas já suportam um motor EVP, caso em que você só precisa configurar os plug-ins. Caso contrário, você terá que escrever uma camada de shim que invoque as funções corretas de sua biblioteca.

Modificando os próprios plug-ins integrados

Pode acontecer que os algoritmos e mecanismos nos plug-ins integrados, descritos na seção anterior, não atendam às necessidades do seu projeto. Nesse caso, você terá que recorrer a modificações no código dos próprios plug-ins, o código que invoca as funções EVP. Por exemplo, você pode fazer pequenas modificações, como selecionar algoritmos diferentes daqueles definidos pela especificação, possivelmente usando tamanhos de chave ou parâmetros de algoritmo diferentes. Como outro exemplo, você pode mudar de link dinâmico para estático, se preferir.

É possível ir além de pequenas alterações e, por exemplo, introduzir um mecanismo de autenticação de identidade totalmente diferente. Seguir esse caminho se torna complicado muito rapidamente e recomendamos fortemente que você entre em contato conosco para discutir suas necessidades e planos. Estamos ansiosos para interagir com você!