Beveilig uw IIoT-systeem met de cryptografiebibliotheek van UW keuze!

Je hebt inmiddels misschien gelezen over de OMG DDS-beveiligingsspecificatie die de bestaande DDS-standaard verbetert met een beveiligingsarchitectuur en -model. Versie 1.0 van die specificatie staat op het punt te worden afgerond door de OMG. Dit betekent dat een datacentrisch beveiligingsmodel nu standaard wordt geïntegreerd in de DDS-standaard - de enige open communicatiestandaard die is ontworpen om de flexibiliteit, betrouwbaarheid en snelheid te bieden die nodig zijn om complexe realtime-applicaties te bouwen, waaronder vele soorten industriële IoT systemen.

Een van de opvallende kenmerken die in DDS Security Spec zijn geïntroduceerd, is het idee van een Service Plugin Interface (SPI)-architectuur. Het mechanisme van SPI's stelt gebruikers in staat om het gedrag en de technologieën die de DDS-implementatie gebruikt voor Information Assurance aan te passen, zonder de applicatiecode te wijzigen.

Deze blogpost legt kort de SPI-architectuur uit en demonstreert een eenvoudige manier om de ingebouwde beveiligingsplug-ins van RTI Connext DDS Secure te gebruiken om geselecteerde cryptografische acties uit te voeren met de cryptografiebibliotheek van uw keuze.

DDS Secure Service Plugin Interfaces (SPI's)

De DDS-beveiligingsspecificatie introduceert geen wijzigingen in de manier waarop applicaties omgaan met de DDS-infrastructuur. In plaats daarvan definieert het vijf verschillende plug-incomponenten die indien nodig door de infrastructuur worden gebruikt. Elk van deze componenten biedt een bepaald aspect van de Information Assurance-functionaliteit en heeft een gestandaardiseerde interface, zoals gedefinieerd door de DDS-beveiligingsspecificatie. Dit is waar de naam Service Plugin Interfaces (SPI's) naar verwijst. De architectuur van de plug-in wordt geïllustreerd in de onderstaande afbeelding.

Zoals u kunt zien, zijn er vijf SPI's die gezamenlijk informatieborging bieden aan DDS-systemen. Hun namen en doeleinden zijn als volgt:

SPI-naam Doel van de typen en bewerkingen AuthenticatieOndersteunt verificatie van de identiteit van DDS DomainParticipant, inclusief faciliteiten om wederzijdse authenticatie uit te voeren en gedeelde geheimen vast te stellen.AccessControlMaak beslissingen over welke beschermde DDS-gerelateerde operaties een geauthenticeerde DDS DomainParticipant mag uitvoeren, inclusief het lid worden van een DDS Domain en het creëren van Topics, DataReaders en DataWriters.CryptographyOndersteunt cryptografische bewerkingen, inclusief encryptie en decryptie, hashing, digitale handtekeningen en berichtauthenticatiecodes.LoggingOndersteunt het loggen van beveiligingsgerelateerde gebeurtenissen voor een DDS Domain Participant.Data TaggingBied de mogelijkheid om een ​​beveiligingslabel of -tag aan gegevens toe te voegen, voor applicatie- specifieke doeleinden.

De SPI-architectuur geeft u veel vrijheid om de Information Assurance-aspecten van uw beveiligde DDS-systeem aan te passen. Alle aspecten genoemd in de bovenstaande bullet list kunnen worden aangepast of opnieuw worden geïmplementeerd door gebruik te maken van uw eigen implementatie van de SPI's. Wat je niet kunt veranderen, is het mechanisme wanneer de DDS-implementatie roept eigenlijk de methoden van de SPI's op -- ze worden alleen aangeroepen wanneer dat nodig is. Dit is eigenlijk een goede zaak, want het betekent dat de middleware zich blijft gedragen zoals voorgeschreven in de specificatie en u zich geen zorgen hoeft te maken dat u die verbreekt.

Naast de interfaces van de SPI's, geeft de DDS Security-specificatie ook een functionele beschrijving van de zogenaamde ingebouwde plug-ins, die in detail worden beschreven in hoofdstuk 9 van dat document. Hun primaire bedoeling is om out-of-the-box interoperabiliteit te bieden tussen verschillende implementaties van DDS Security. Met RTI Connext Secure DDS zijn de ingebouwde plug-ins ook een uitstekend startpunt voor maatwerk.

De RTI Connext DDS Secure ingebouwde plug-ins aanpassen

De ingebouwde binaire bestanden van de beveiligingsplug-in die bij Connext DDS Secure worden geleverd, kunnen out-of-the-box worden gebruikt om uw DDS-systeem met Information Assurance te maken. Het enige wat u hoeft te doen is de PropertyQosPolicy van uw DomainParticipant correct te configureren, zoals uitgelegd in de specificatie, om te verwijzen naar de gewenste beveiligingsartefacten zoals toegangscontrole- en governanceconfiguratiebestanden en identiteitscertificaten, onder andere.

Voor degenen die het gedrag van de plug-ins willen wijzigen, is er ook een set bouwbare broncodebestanden beschikbaar. Voor veel situaties bieden de Connext DDS Secure-plug-ins echter een veel eenvoudigere optie. Voer de OpenSSL EVP API in...

Verwisselen van cryptografische algoritme-implementaties

De ingebouwde broncode van Connext DDS Secure-plug-ins maakt gebruik van de cryptografische OpenSSL-bibliotheek -- niet voor zijn SSL- of TLS-functionaliteit, maar voor zijn reeks cryptografische functie-implementaties en een aantal hulpklassen die daarbij worden gebruikt. Als u bekend bent met OpenSSL-programmering, weet u dat het een goede gewoonte is om gebruik te maken van de zogenaamde EVP-interface. (Voor het geval je je afvraagt, zoals ik deed:EVP staat voor EnVeloPe.) De Connext DDS Secure-plug-ins roepen een subset van zijn functies op, namelijk die gerelateerd aan de items in de onderstaande tabel:

Functionaliteit Algoritmen gespecificeerd voor ingebouwde DDS-beveiligingsplug-ins Symmetrische codering en decoderingAES in Galois Counter Mode (GCM) voor 128-bits of 256-bits sleutelgroottesOndertekenen en verifiëren van RSA-PSS- of ECDSA-handtekeningalgoritmen met SHA-256 als hun hashfunctieKey exchangeDiffie-Hellman met behulp van modulaire rekenkunde (DH) of elliptische krommen ( ECDH), met gespecificeerde parameters BerichtauthenticatiecodesHMAC, met met SHA-256 als hashfunctie, en GMACSecure hash-functiesSHA-256 Willekeurige nummergeneratie Elke cryptografisch sterke generator voor willekeurige getallen

De plug-ins die worden geleverd met het product gebruikt de OpenSSL-implementaties van deze functies, zoals te vinden in de standaard OpenSSL EVP-engine. Ze ondersteunen echter ook het invoegen van uw eigen engine. Uw OpenSSL-engine-implementatie kan andere implementaties van deze cryptografische functies aanroepen, bijvoorbeeld door gebruik te maken van de cryptografische bibliotheek van uw keuze, misschien omdat u FIPS-compatibele implementaties moet gebruiken. Sommige bibliotheken ondersteunen al een EVP-engine, in dat geval hoeft u alleen de plug-ins te configureren. Anders moet je een shim-laag schrijven die de juiste functies uit je bibliotheek aanroept.

De ingebouwde plug-ins zelf aanpassen

Het kan gebeuren dat de algoritmen en mechanismen in de ingebouwde plug-ins, zoals beschreven in de vorige sectie, niet voldoen aan de behoeften van uw project. In dat geval zul je je toevlucht moeten nemen tot aanpassingen in de code van de eigenlijke plug-ins, de code die de EVP-functies aanroept. U kunt bijvoorbeeld kleine wijzigingen aanbrengen, zoals het selecteren van andere algoritmen dan die gedefinieerd door de specificatie, mogelijk met behulp van verschillende sleutelgroottes of algoritmeparameters. Een ander voorbeeld:u kunt desgewenst overschakelen van dynamische naar statische koppeling.

Het is mogelijk om verder te gaan dan kleine wijzigingen en bijvoorbeeld een geheel ander identiteitsverificatiemechanisme te introduceren. Dat pad bewandelen wordt al snel ingewikkeld en we raden je ten zeerste aan om contact met ons op te nemen om je behoeften en plannen te bespreken. We kijken ernaar uit om met u in gesprek te gaan!