Zabezpečená komunikace u PLC rychle nabývá na významu a u některých projektů je nasazení PLC s TLS (Transport Layer Security) zabezpečením již podmínkou. V následujícím textu se seznámíme se základy šifrování a ověřování a ukážeme si některé scénáře z hlediska projektování a aplikačního programování. Více informací k celé problematice, podrobnější popisy navazování spojení a podobně jsou k nalezení na Internetu, zde se budeme věnovat jen základním principům a zejména dopadům na organizaci projektu a nastavení PLC a dalších programů. Někdy se setkáme se zkratkou SSL (Secure Socket Layer), TLS je její modernější nástupce.
Při zabezpečeném přenosu dat se, zjednodušeně řečeno, řeší dva problémy:
Šifrování probíhá tak, že při navazování spojení si obě strany dohodnou pravidla a postupy pro šifrování, zabezpečeným způsobem si nasdílí šifrovací klíč a pak data (která by normálně byla posílána nešifrovaně) vždy na straně odesílatele zašifrují a na straně příjemce dešifrují. O to se stará právě protokol TLS, který je „mezi“ TCP a aplikačním protokolem, kterým je například SSCP v případě komunikace mezi Domat IDE a PLC, nebo HTTP u webového přístupu. Výsledkem je to, že veškerá data, která putují mezi oběma subjekty, jsou pro jakoukoli cizí stranu (která nemá přístup ke klíči) nečitelná.
Pro ověřování slouží tzv. certifikáty, což jsou elektronicky podepsaná prohlášení, že strana, která zasílá certifikát, má nějaké vlastnosti – například „je webový server na určité doméně“. Elektronický podpis se ověřuje pomocí certifikátu, kterému musí přijímající strana věřit. Důvěryhodnost představuje například to, že certifikát byl do úložiště zařízení (PLC, počítač) nahrán programátorem při uvádění do provozu. Certifikát se ale může „opírat“ o jiný certifikát, vydaný důvěryhodnou autoritou, jejíž certifikát přijímací strana má a důvěřuje jí. Tomuto řetězení se říká „řetězec důvěry“.
Pro šifrovanou komunikaci pomocí TLS (přesněji řečeno pro utajenou výměnu symetrického šifrovacího klíče) je použito asymetrické šifrování, které je postaveno na dvou klíčích: privátním (soukromém) a veřejném.
Privátní klíč je uložen na serveru. Vygenerování privátního klíče není těžké, jde o textový soubor s kódem, nezávislým na ničem jiném (jako například jméno uživatele, heslo, datum, MAC adresa počítače atd.). Privátní klíč je nutné udržovat v tajnosti, nemělo by být možné ho ze zařízení nijak vyčíst. U PLC je dnes uložen normálně jako soubor, přístup přes SSH k němu lze zablokovat změnou hesla pro uživatele root, v budoucnu bude SSH defaultně zablokované (a pro servisní účely půjde povolit v IDE v rámci konfigurace PLC – tedy se znalostí hesla pro uživatele admin).
Veřejný klíč se při vytváření matematicky odvozuje od privátního klíče a je zasílán protistraně (zde klientovi) v rámci úvodní komunikace, aby protistrana mohla zašifrovat zprávu. Tu lze následně rozšifrovat pouze pomocí privátního klíče, takže to nedokáže nikdo jiný než jeho držitel (zde server).
K ověřování totožnosti slouží (serverový) certifikát, což je, jak jsme si řekli výše, důvěryhodná informace o tom, co je server zač. Součástí certifikátu je i veřejný klíč, aby protistrana mohla odesílat zpět zašifrované zprávy. Důvěryhodnost certifikátu se zajišťuje pomocí elektronického podpisu. Je několik možností, jak certifikát podepsat:
Do každé položky v PLC (user_ca, default_ca) lze nahrát pouze 1 soubor s certifikátem, při dalším nahrání se původní obsah maže. Při nahrání nového je starý certifikát přehrán. Jelikož ale certifikáty jsou textové soubory, lze jejich obsahy slučovat a pokud potřebujeme v PLC mít nahraných více certifikátů (například při zabezpečené komunikaci mezi více PLC na Internetu), je možné všechny potřebné certifikáty nakopírovat do jednoho souboru a nahrát tento soubor. V tuto chvíli ale platí omezení, že jeden soubor s certifikáty nesmí mít velikost větší než 4 kB.
Do PLC lze zatím nahrát pouze serverový certifikát. Co to znamená? Klientské programy mohou ověřovat totožnost PLC jako serveru, ale servery nemohou ověřovat totožnost PLC v roli klienta, což se týká spojení PLC na proxy server a PLC do databáze Merbon DB. Spojení je v tomto případě sice šifrované, ale server nemůže ověřit, že PLC je to, za něž se prohlašuje. Ověření PLC jako klienta probíhá pouze na základě jména a hesla k databázi, ne systémem certifikátů.
Certifikát generuje certifikační autorita na základě žádosti o podpis certifikátu (CSR), která obsahuje:
Při běžné instalaci celý proces vydání certifikátu zajišťuje IT oddělení, které spravuje síť, v níž budou zařízení instalována. Při předávání privátních klíčů, které je nutno držet v tajnosti, může být vyžadováno osobní převzetí, ochrana importu certifikátů heslem, jež je posíláno odděleným kanálem (SMS), atd. Doporučuje se proto všechny potřebné kroky domluvit předem, aby na ně byla dostatečná časová rezerva. Správce sítě stanoví potřebnou bezpečnostní politiku a je nutné s ním domluvit, kdo bude celý systém bezpečnosti spravovat a aktualizovat – IT oddělení provozovatele, dodavatel řídicího systému, nebo nějaký externí subjekt.
Certifikáty a klíče mají omezenou dobu platnosti, obvykle na 2 roky. Čas k porovnání se bere z RTC PLC. Po uplynutí data platnosti je certifikát neplatný. Self-signed certifikáty lze generovat až na 50 let, na podobně dlouhou dobu je generován i certifikát domat_CA. Slouží tedy spíše pro testy a ověření funkce, v produkčním prostředí by měly být nasazeny certifikáty s kratší dobou platnosti. Zároveň je nutné zajistit, aby certifikáty byly pravidelně obnovovány. To je starost provozovatele zařízení, který si ovšem může službu objednat u realizační firmy, která instalovala a programovala řídicí systém. Realizační firma by měla provozovatele na toto upozornit a poskytnout potřebnou součinnost.
Pokud je při spojení vyžadována validace certifikátu a certifikát již pozbyl platnosti, spojení není navázáno. Tato bezpečnostní vlastnost se může stát „časovanou bombou“ – zařízení náhle přestane komunikovat, ačkoli v nastavení nikdo nic neměnil. Problém poznáme podle záznamu v systémovém logu PLC.
Pro zajímavost a hlubší pochopení - komunikace probíhá přibližně takto:
Podrobnější popis viz např. https://tls13.ulfheim.net/.
Dialog v PLC (PLC – Operace s PLC – Nahrání certifikátů) vypadá takto:
V IDE není vidět, zda v PLC jsou již nějaké certifikáty nahrány. Při nahrání se staré přemažou.
Nahrávací proces v Domat IDE nijak nekontroluje formát, konzistenci souboru a podobně. Libovolné jméno .pem souboru se změní na název souboru, specifický pro typ certifikátu nebo klíče, a pod tímto názvem se soubor uloží v PLC. Když je položka nevyplněná, v PLC zůstává původní soubor.
| Položka k nahrání | Název souboru v PLC |
| Default CA | def_ca |
| User CA | usr_ca |
| Server Private Key | srv_key |
| Server Certificate | srv_cert |
| Web Server Certificate | web |
| Web Server Certificate Key | web_key |
Dvojice Web Server Certificate a Web Server Certificate Key slouží pro webový přístup. Je nezávislá na Server Certificate a Server Private Key, ty jsou pro SSCP server.
Pokud je klíč chráněn heslem, při importu do úložiště je nutné toto heslo zadat. Heslo by se mělo z bezpečnostních důvodů posílat zvláštním komunikačním kanálem, např. přes SMS nebo ústně. PLC import zaheslovaného klíče neumí, je nutné klíč vyžádat v nezašifrovaném tvaru nebo odemknout pomocí odemykacího programu. Nezašifrovaný privátní klíč je nutné chránit proti zneužití!
V další části se podíváme na jednotlivé komunikační scénáře a ukážeme si, jaké mají možnosti zabezpečení.
