¡Asegure su sistema IIoT con la biblioteca de criptografía de SU elección!

A estas alturas, es posible que haya leído sobre el OMG Especificación de seguridad DDS que mejora el estándar DDS existente con una arquitectura y un modelo de seguridad. La versión 1.0 de esa especificación está a punto de ser finalizada por el OMG. Esto significa que un modelo de seguridad centrado en datos ahora se integrará de forma nativa en el estándar DDS, el único estándar de comunicaciones abierto que fue diseñado para brindar la flexibilidad, confiabilidad y velocidad necesarias para construir aplicaciones complejas en tiempo real, incluidos muchos tipos de IoT industrial. sistemas.

Una de las características sorprendentes introducidas en DDS Security Spec es la noción de una arquitectura de interfaz de complemento de servicio (SPI). El mecanismo de los SPI permite a los usuarios personalizar el comportamiento y las tecnologías que utiliza la implementación de DDS para el aseguramiento de la información, sin cambios en el código de la aplicación.

Esta publicación de blog explica brevemente la arquitectura SPI y demuestra una manera fácil de aprovechar los complementos de seguridad integrados de RTI Connext DDS Secure para que ejecuten acciones criptográficas seleccionadas con la biblioteca de criptografía de tu elección.

Interfaces de complementos de servicio seguro (SPI) de DDS

La Especificación de seguridad DDS no introduce ningún cambio en la forma en que las aplicaciones interactúan con la infraestructura DDS. En cambio, define cinco componentes de complementos diferentes que la infraestructura aprovecha cuando es necesario. Cada uno de esos componentes proporciona un cierto aspecto de la funcionalidad de Aseguramiento de la Información y tiene una interfaz estandarizada, como se define en la Especificación de Seguridad DDS. Esto es a lo que se refiere el nombre Service Plugin Interfaces (SPI). La arquitectura del complemento se ilustra en la imagen a continuación.

Como puede ver, hay cinco SPI que colectivamente brindan Aseguramiento de la Información a los sistemas DDS. Sus nombres y propósitos son los siguientes:

Nombre SPI Finalidad de sus tipos y operaciones Autenticación Admite la verificación de la identidad de los participantes del dominio DDS, incluidas las facilidades para realizar la autenticación mutua y establecer secretos compartidos. Control de acceso Tomar decisiones sobre qué operaciones protegidas relacionadas con DDS puede realizar un participante del dominio DDS autenticado, incluida la unión de un dominio DDS y la creación de temas, lectores de datos y DataWriters.CryptographySupport operaciones criptográficas, incluyendo cifrado y descifrado, hash, firmas digitales y códigos de autenticación de mensajes. propósitos específicos.

La arquitectura SPI le da mucha libertad para personalizar los aspectos de Aseguramiento de la Información de su sistema DDS seguro. Todos los aspectos mencionados en la lista de viñetas anterior se pueden modificar o volver a implementar utilizando su propia implementación de los SPI. Lo que no se puede cambiar es el mecanismo cuando la implementación de DDS en realidad invoca los métodos de las SPI, simplemente se invocan cuando es necesario. Esto es realmente algo bueno porque significa que el middleware continúa comportándose según lo prescrito en la especificación y no tiene que preocuparse por romper eso.

Además de las interfaces de los SPI, la especificación de seguridad DDS también proporciona una descripción funcional de los llamados complementos incorporados, descritos en detalle en el Capítulo 9 de ese documento. Su intención principal es proporcionar interoperabilidad lista para usar entre diferentes implementaciones de DDS Security. Con RTI Connext Secure DDS, los complementos integrados también resultan ser un excelente punto de partida para la personalización.

Personalización de los complementos integrados de RTI Connext DDS Secure

Los archivos binarios de complementos de seguridad incorporados que se envían con Connext DDS Secure se pueden utilizar de forma inmediata para crear su sistema DDS que incluye la garantía de la información. Todo lo que necesita hacer es configurar correctamente PropertyQosPolicy de su DomainParticipant como se explica en la especificación para apuntar a los artefactos de seguridad deseados como control de acceso y archivos de configuración de gobierno, así como certificados de identidad, entre otros.

Para aquellos que deseen modificar el comportamiento de los complementos, también se proporciona un conjunto de archivos de código fuente compilables. Sin embargo, para muchas situaciones, los complementos de Connext DDS Secure ofrecen una opción mucho más sencilla. Ingrese la API de OpenSSL EVP ...

Cambio de implementaciones de algoritmos criptográficos

El código fuente integrado de los complementos de Connext DDS Secure hace uso de la biblioteca criptográfica OpenSSL, no por su funcionalidad SSL o TLS, sino por su conjunto de implementaciones de funciones criptográficas y una serie de clases auxiliares utilizadas con esos. Si está familiarizado con la programación OpenSSL, sabrá que es una buena práctica aprovechar la llamada interfaz EVP. (En caso de que se lo esté preguntando, como hice yo:EVP significa EnVeloPe). Los complementos de Connext DDS Secure invocan un subconjunto de sus funciones, a saber, las relacionadas con los elementos de la siguiente tabla:

Funcionalidad Algoritmos especificados para complementos de seguridad DDS integrados Cifrado y descifrado simétrico AES en modo contador Galois (GCM) para tamaños de clave de 128 bits o 256 bits Firma y verificación de algoritmos de firma RSA-PSS o ECDSA con SHA-256 como función hash Intercambio de claves Diffie-Hellman mediante aritmética modular (DH) o curvas elípticas ( ECDH), con parámetros especificados, códigos de autenticación de mensajes HMAC, con SHA-256 como función hash y GMAC Funciones hash seguras SHA-256 Generación de números aleatorios Cualquier generador de números aleatorios criptográficamente fuerte

Los complementos enviados con el producto utiliza las implementaciones OpenSSL de estas funciones, como se encuentra en el motor estándar OpenSSL EVP. Sin embargo, también admiten la inserción de su propio motor. La implementación de su motor OpenSSL podría invocar otras implementaciones de estas funciones criptográficas, por ejemplo, aprovechando la biblioteca criptográfica de su elección, tal vez porque debe utilizar implementaciones compatibles con FIPS. Algunas bibliotecas ya admiten un motor EVP, en cuyo caso solo tiene que configurar los complementos. De lo contrario, tendrá que escribir una capa de corrección que invoque las funciones correctas de su biblioteca.

Modificación de los complementos incorporados

Puede suceder que los algoritmos y mecanismos de los complementos integrados, descritos en la sección anterior, no satisfagan las necesidades de su proyecto. En ese caso, tendrás que recurrir a realizar modificaciones en el código de los complementos reales, el código que invoca las funciones de EVP. Por ejemplo, puede realizar pequeñas modificaciones como seleccionar algoritmos diferentes a los definidos por la especificación, posiblemente usando diferentes tamaños de clave o parámetros de algoritmo. Como otro ejemplo, puede cambiar de enlace dinámico a estático si lo prefiere.

Es posible ir más allá de los cambios menores y, por ejemplo, introducir un mecanismo de autenticación de identidad completamente diferente. Seguir ese camino se vuelve complicado con bastante rapidez y le recomendamos que se comunique con nosotros para discutir sus necesidades y planes. ¡Esperamos poder relacionarnos con usted!