Industriële fabricage
Industrieel internet der dingen | Industriële materialen | Onderhoud en reparatie van apparatuur | Industriële programmering |
home  MfgRobots >> Industriële fabricage >  >> Industrial Internet of Things >> Internet of Things-technologie

DDS-beveiliging op de hard(ware) manier - SGX:deel 1 (overzicht)

Deel 1 van een meerdelige Serie

Het beschermen van bedrijfskritieke industriële IoT-omgevingen vereist beveiliging die schaalbaar is van edge naar cloud, over systemen en leveranciers heen. Als hoofdauteur van de OMG DDS-beveiligingsstandaard heeft RTI een leidende rol gespeeld bij het definiëren van de vereisten - en omgevingen - die nodig zijn om gedistribueerde omgevingen te beveiligen. DDS Security-plug-ins bieden robuuste, datagerichte beveiligingsmechanismen voor data on the wire. RTI Connext DDS Secure is het beproefde, vertrouwde connectiviteitsraamwerk dat systemen beschermt door middel van flexibele, fijnmazige beveiliging voor optimale prestaties en efficiëntie, van apparaat tot cloud.

We erkennen echter dat beveiliging een complex vraagstuk is. Hoewel RTI hoogwaardige beveiliging heeft gecreëerd in het Connext DDS-softwareframework, kijkt ons onderzoeksteam naar andere gebieden om een ​​robuustere beveiliging in IIoT te brengen. Met dit in gedachten delen we graag een deel van het werk van RTI Research, terwijl ze nieuwe en innovatieve benaderingen van beveiliging onderzoeken.

In deze blogserie kijkt onze beveiligingsexpert Jason Upchurch verder dan de software naar hardwaremechanismen die beveiliging bieden op een onbetrouwbaar systeem waar een kritieke applicatie zijn gegevens verwerkt. In de geest van het pushen van de beveiligingsenvelop, verkent hij Intel SGX® in de context van RTI Connext® DDS Micro en Security Plugins.

Dus laten we beginnen.

Wat is SGX en waarom is het belangrijk?

SGX, of Software Guard Extensions, is een uitbreiding op de Intel ISA (Instruction Set Architecture) die een TEE (Trusted Execution Environment) biedt om applicaties uit te voeren die gevoelige gegevens bevatten. Hoewel het waar is dat Intel ISA het industriële IoT (IIoT) niet domineert, heeft het wel marktaandeel in de serverruimte en is de serverruimte vaak geïntegreerd in verschillende IIoT-architecturen. Sterker nog, deze toepassingen voor gegevensverwerking in de serverruimte zijn eerder hoogwaardige doelen van kwaadwillende gebruikers, omdat ze mogelijk meer toegang hebben tot beschermde gegevens dan traditionele IIoT-eindpunten. SGX zou dus heel goed kunnen helpen het IIoT te beveiligen, of op zijn minst een deel ervan. Laten we eens kijken waarom SGX belangrijk is voor DDS-gebruikers en andere applicatieontwikkelaars die omgevingen met een hoge beveiliging nodig hebben.

Figuur 1:Connext DDS Secure Inside SGX Space

Over-the-Wire-beveiliging is misschien niet genoeg

Laten we om te beginnen eens kijken naar het klassieke academische voorbeeld van Alice en Bob van het delen van een geheim. Het verhaal begint met Alice en Bob die elkaar persoonlijk ontmoeten, gaat verder met een sluwe Eve die berichten op de draad onderschept en eindigt met een beproefde methode om geheimen te delen. Dit is de basis voor veilige communicatie, ook als Eve alle berichten onderschept. Na verschillende van 's werelds grootste inbraakonderzoeken te hebben uitgevoerd, kan ik gerust zeggen dat ik "Eve" nog nooit versleutelde berichten op de draad heb zien onderscheppen en geheimen hebben verzameld. Ik kan ook met zekerheid zeggen dat "Eva" bijna altijd de geheimen krijgt waar ze naar op zoek is. Deze schijnbaar tegenstrijdige verklaringen kunnen beide waar zijn, omdat netwerkversleuteling robuust is en daarom zelden het doelwit van aanvallen.

Om het probleem te onderzoeken, laten we eens kijken naar het scenario, waar Eve tussen Alice en Bob zit en berichten naar believen kan horen en zelfs manipuleren. Het scenario gaat ervan uit dat Alice en Bob elkaar vertrouwen met de geheimen die ze delen; deze veronderstelling blijkt in de praktijk echter erg gebrekkig te zijn. Het tekstboekdiagram in figuur 2 illustreert eigenlijk het probleem, aangezien Alice schijnbaar op afstand met Bob communiceert zonder enige technologie.

Figuur 2:Tekstboek Alice en Bob communicatie

De realiteit van de situatie is dat er een of ander apparaat wordt gebruikt om Alice en Bob in staat te stellen te communiceren, en dit is waar onze veronderstelling de overhand krijgt. Op het gebied van computerbeveiliging is er een concept dat bekend staat als de Trusted Computing Base (TCB). In de eenvoudigste bewoordingen is TCB alle componenten (zowel afzonderlijk als als een systeem), inclusief software, die u moet vertrouwen om een ​​soort van verwerking te beveiligen. In ons klassieke Alice en Bob-scenario proberen we het delen van geheimen op afstand veilig te stellen. Het is waar dat Alice ervan uitgaat dat ze op Bob vertrouwt om geheimen met hem te delen, maar ze vertrouwt ook op zijn computeromgeving (en de hare). In een realistisch scenario is dit een ensemble van honderden componenten van verschillende fabrikanten die (a) waarschijnlijk een besturingssysteem draaien met miljoenen regels code; (b) staat vol met applicaties die zijn gecodeerd door mensen die u niet kent; en (c) waarschijnlijk verbonden met een openbaar netwerk dat aanvallers en automatisch verspreidende malware gratis toegang geeft om het systeem naar believen aan te vallen. Deze systemen zijn op zijn zachtst gezegd verre van betrouwbaar.

...de situatie is vergelijkbaar met het bouwen van een stalen deur met uitgebreide sloten op een huis met papieren muren.

Het is de bron van cynische humor voor velen in de computerbeveiligingsgemeenschap wanneer een nieuw en beter versleutelingsschema wordt aanbevolen om communicatie over de draad te versleutelen. Geheimen kunnen immers met weinig moeite uit de bron of bestemming worden geplukt, volledig in het reine, zonder dat u zich zorgen hoeft te maken over versleuteling. Ik heb altijd gedacht dat de situatie analoog is aan het bouwen van een stalen deur met uitgebreide sloten op een huis met papieren muren.

Dus wat is er te doen? De huidige benadering in de industrie is grotendeels gericht op het vinden van de minimaal haalbare componenten (hardware en software) die nodig zijn om een ​​kritieke taak uit te voeren, elk onderdeel te certificeren en/of te meten en deze te isoleren van andere componenten in het systeem. Op een heel basaal niveau verkleint deze benadering de TCB en verifieert dat er geen onderdeel binnen de TCB is toegevoegd of gewijzigd.

Beveiliging op het eindpunt (en elk punt ertussen)

Het is nuttig op te merken dat, hoewel niet triviaal, we op het gebied van informatica het punt hebben bereikt dat het mogelijk is om een ​​veilige computeromgeving te bouwen. Het probleem is dat de huidige marktvraag is naar een rijke computeromgeving, wat op gespannen voet staat met een veilige. Zelfs in IIoT is de vraag naar rijke computeromgevingen niet altijd vanwege de enorme functionaliteit die ze bieden, maar omdat ze populair zijn en goed worden ondersteund, dus veel goedkoper om te ontwikkelen en te onderhouden. Dus het grote TCB-probleem vindt zijn weg naar apparaten die met een andere aanpak kunnen worden beveiligd. Als antwoord op dit probleem is de industrie begonnen met het ontwerpen van systemen die zowel een rijk besturingssysteem als een (op de een of andere manier) gescheiden Trusted Execution Environment (TEE) in één apparaat bieden.

De meeste TEE-ontwerpen hebben in wezen twee besturingssystemen die parallel op één apparaat draaien. Het rijke besturingssysteem handelt veelvoorkomende taken af ​​en het veilige besturingssysteem handelt gevoelige taken af. Het TEE-ontwerp maakt het mogelijk om tussen de twee te schakelen. De switch wordt vaak hardware ondersteund en afgedwongen. Gemeenschappelijke vertrouwensmechanismen – zoals het laden van de root of trust chain – worden aan de veilige kant gebruikt om ervoor te zorgen dat er geen ongeautoriseerde code is geïntroduceerd.

SGX is heel anders. Zelfs een beveiligde TCB aan de zijkant kan behoorlijk groot zijn. De root of trust zorgt er alleen voor dat een programma bij het laden ongewijzigd blijft. Als zodanig hangt de beveiliging ervan af van softwarevalidatietechnieken voor elk geladen programma (inclusief het minimale besturingssysteem) en evenzeer van het vertrouwde opstartproces. Intel wilde de TCB radicaal minimaliseren. Het aanvalsoppervlak in een SGX-enabled processor is de CPU en de applicatie. Er is geen besturingssysteem, firmware, hypervisor, andere hardware of BIOS die vertrouwd moet worden in een SGX-omgeving. De enige software die vertrouwd moet worden, is de applicatie zelf. SGX biedt een methode om ervoor te zorgen dat die applicatie vertrouwd wordt geladen op vrijwel dezelfde manier als een normale vertrouwde opstart, behalve dat de vertrouwensketen slechts 3 schakels lang is (Root Attestation, CPU, Applicatie) in plaats van de vrij lange ketens in een traditionele veilige opstartsysteem.

Figuur 3:Aanvalsoppervlak in een SGX-omgeving

Ik heb geëxperimenteerd met Intel SGX en DDS+Security. Mijn doel is om een ​​DDS-toepassing uit te voeren in een bescher

[1] [2] 下一页

Internet of Things-technologie

  1. DDS-beveiliging op de hard(ware) manier - SGX Deel 3:Geharde DDS-services
  2. DDS-beveiliging op de hard(ware) manier - SGX:deel 2 (Micro + beveiliging + SCONE)
  3. De weg naar industriële IoT-beveiliging
  4. Beveiligingsproblemen van het industriële IoT aanpakken
  5. Het IoT beveiligen tegen cyberaanvallen
  6. De IoT-bedreigingsvector beveiligen
  7. De beveiligingsuitdaging van het internet der dingen:deel 2
  8. De beveiligingsuitdaging van het internet der dingen:deel 1
  9. Het industriële IoT beschermen:een aanpak van de volgende generatie aannemen – deel 2
  10. Beveiliging versterkt het ware potentieel van IoT
  11. UID-overzichtsreeks – Deel III – De toekomst van UID