Zabezpečení výrobních zařízení v továrně

[veskotskujehnusne]

Ahoj, řešíme takový zapeklitý problém, který mám dojem, že nemá nijak jednoduché řešení.

Máme v továrnách zařízení na oživování našich produktů. Obvykle je to Raspberry PI. Jsou tam nějaké interní nástroje, které generují hesla a podobně. Přišel požadavek, abychom to celé zabezpečili, aby z toho nebyl nikdo schopen vytahat takto citlivá data. Ale co s tím, když se tato zařízení běžně vypínají a musí fungovat po naběhnutí? Zašifrování čehokoli musí být obsluze známým heslem rozšifrovatelné, když to ráno najede. Nějak mě tedy napadá, co s tím, ale možná mi jen něco uniká. Nějaké nápady, prosím?

[Reklama]

[Foreigner]

Ahoj, řešíme takový zapeklitý problém, který mám dojem, že nemá nijak jednoduché řešení.

Máme v továrnách zařízení na oživování našich produktů. Obvykle je to Raspberry PI. Jsou tam nějaké interní nástroje, které generují hesla a podobně. Přišel požadavek, abychom to celé zabezpečili, aby z toho nebyl nikdo schopen vytahat takto citlivá data. Ale co s tím, když se tato zařízení běžně vypínají a musí fungovat po naběhnutí? Zašifrování čehokoli musí být obsluze známým heslem rozšifrovatelné, když to ráno najede. Nějak mě tedy napadá, co s tím, ale možná mi jen něco uniká. Nějaké nápady, prosím?

Resim to tak ze se pri spusteni se nastartuje unita s python scriptem, ktery vytahne z db heslo pro dane zarizeni a nasledne odsifruje disk a pripoji. Vsechna dulezita data jsou na jednom zasifrovanem oddilu.  Pouzivam encfs.

[Jakub Štech]

Jestli to máte na síti, tak stačí i něco tak hloupýho, jako program, co se v určitou hodinu (před začátkem výroby) připojí přes ssh na to zařízení a několika příkazy dešifruje klíč (do RAM).

[_Jenda]

Obvykle je to Raspberry PI. Jsou tam nějaké interní nástroje, které generují hesla a podobně.

Nejlepší řešení je zamyslet se, jestli opravdu takové nástroje musí být tajné. Z popisu "generují hesla" toho samozřejmě nejde moc poznat, ale to, že tvrdíte, že samotné získání nástroje pro generování hesel znamená problém, ukazuje, že velmi pravděpodobně máte problém někde jinde - hesla jsou deterministická, používají se na více místech atd. To je obecně špatný security design.

Popište situaci, v čem je problém, pravděpodobně ji dokážeme vyřešit tak, jak se správně má.

Přišel požadavek, abychom to celé zabezpečili, aby z toho nebyl nikdo schopen vytahat takto citlivá data. Ale co s tím, když se tato zařízení běžně vypínají a musí fungovat po naběhnutí? Zašifrování čehokoli musí být obsluze známým heslem rozšifrovatelné, když to ráno najede. Nějak mě tedy napadá, co s tím, ale možná mi jen něco uniká. Nějaké nápady, prosím?

Nelze, Raspberry nemá žádné TPM ani jiný způsob, jak zjistit, zda si do něj někdo nainstaloval backdoor. Na tom padají i ty další dvě odpovědi, co se tu objevily.

[RDa]

Jsou dve varianty:

- to zarizeni by nemelo byt pripojene do site, ale izolovane nekde v kleci pod zamkem. A vyrobky by meli tuto zonu navstivit jen jako posledni krok, pro nainstalovani krypto obsahu

- oddelit hw a sw - samotne IP, knowhow a SW ktere resi cryptoshit mit na zabezpecenem serveru (at si vase vedeni zaridi tohle nejprve) a pak k vyrobkum na lince plne neproverenych lidi mit jenom hw interface, ktery bude provadet ukony na vyrobku. Kod muze bezet v /dev/shm, kdyz udelate mount -o remount,exec ... a po kazdem ukonu ho lze smazat

Ale pokud tam mate nejake serioznejsi schemata, je cas zjistit co znamena HSM a nechat si poradit od dodavatele, ktery na rozdil od zdejsiho publika vam poradi na miru.

[Reklama]

[František Ryšánek]

Um. Na okraj mi tady vysvítá otázka, zda "požadavek na vyšší zabezpečení" přišel od zákazníka, nebo od šéfa tazatele v rámci dodavatelské firmy :-)

= zda je cílem chránit zákazníkova hodnotná data (designy výrobků, CAM data, provozně-výrobní statistiky apod.), nebo zabránit zákazníkovi, aby si dokázal zálohovat OS/FW a svépomocně ho opravit v případě, že hardware zmíněného "šémového RPi" jednoho dne umře. (Nedejbože klonovat/namnožit licencovanou řídící jednotku s úmyslem ušetřit za licence apod.)

V praxi potkávám oba zájmy :-)
A řešení jsou možná v obou případech podobná, protože podobné budou i "vektory útoku" = v prvé řadě fyzický přístup, znalost architektury a bootovací sekvence počítače na bázi RPi, nahraditelnost hardwaru "kus za kus". Otázkou je, zda to smí/nesmí/musí komunikovat po LAN a co je obsahem té komunikace apod.

Možná ještě třetí motiv: zabránit v neautentikovaném přístupu do firemní LAN skrz neprověřené zařízení...

[PanVP]

Tohle se přeci řeší jen bufferem  

RPI zachytává data a pokud je nedokáže odeslat hned, ukládá je do bufferu.

V krocích:
RPi zapnu
- běžný FS není šifrován (jen by to dělalo problémy)
- RPi se přihlásí k serveru třeba přes HTTPS, prokáže se certifikátem, odešle svůj identifikátor
(Certifikát může být platný třeba 30 let.)
- RPI získá ze serveru heslo k lokálnímu šifrovanému úložišti (tj.extra USB) (poslané přes HTTPS klidně v nešifrované podobě)
- zařízení získá i svojí konfiguraci (super centrální management)
- úložiště rozšifruje buffer/dočasné úložiště (samostatný USB disk)
- Pokud přijímaná/odesílaná data nelze ihned odeslat na server, jdou do bufferu
- veškerá komunikace běží po HTTPS

Je to zašifrované, je to hlídané, na zařízení nejsou volně se povalující data...co chcete víc ?

Jak se to zprovozní:
- nainstaluji
- součástí instalace je přidání certifikátu serveru
- zařízení dostane certifikát
- ten se nastaví i na serveru
- vygeneruje se pro něj konfigurace
- done...

Pokud je požadavek to zabezpečit víc, musí se použít něco s TPM čipem, jak samozřejmě správně napsal RDa.

[PanVP]

Pro informaci, pro RPi jsou TPM moduly, třeba tento:
https://buyzero.de/products/letstrust-hardware-tpm-trusted-platform-module

A postup rozběhnutí třeba tady:
https://github.com/joholl/rpi4-uboot-tpm

Nevýhody jsou zřejmé (cena, spolehlivost, vícepráce).

Takže lepší je použít něco, co je 100% standardní a už má TPM modul v sobě.
https://ark.intel.com/content/www/us/en/ark/products/130393/intel-nuc-kit-nuc7i7dnhe.html
https://www.intel.com/content/www/us/en/support/articles/000007452/intel-nuc.html

[František Ryšánek]

Obecnou vlastností několika generací NUCů s plnotučnými procesory je vysoká teplota. Do průmyslu nedoporučuji. Na uvedené použití skutečně stačí to nejslabší, co vyhoví účelu a nebude moc hřát. Pokud ne malina (ta umí hřát, a není moc průmyslová) tak třeba nějaký Vortex (x86 32bit) nebo spodní konec Intelových ATOMů. Pokud je zároveň výhodou "security by obscurity", tak třeba nějaký COM/SOM modul, který bez devkitu ani nepřipojíte k displeji. Může to mít onboard eMMC flashku jako bootovačku, takže nehrozí "vytáhnu SDčko a ve čtečce si ho přečtu". Onboard je taky RAMka a aspoň jeden Ethernet. Tuším jsem viděl takovou desku s dvoujádrovým asi 1.3 GHz BayTrailem nebo Braswellem, formát desky Qseven COM, samotný SoC žere 3-4 W (TDP), další třeba dva watty přidá RAM a LAN. Ale je fakt, že to znamená, navrhnout si nosnou desku a nechat ji vyrobit.

Jo a TPM to koukám v základu nemá... viděl jsem ho u Congatecu na jiných platformách, tuším přes SPI, což tuším z x86 vytáhnout nejde. Možná na USB.

[František Ryšánek]

Tohle je v krabičce a má to Braswell, zbytečně čtyřjádro TDP=5W, jako option to může mít TPM. Není to úplně obskurní, protože to má SD slot a SATA. A nemá to průmyslový rozsah teplot... nenaděláš nic.

[PanVP]

Velmi se obávám, že pořídit něco vhodného do průmyslu s TPM čipem - za cenu RPI bez TPM, bude mimořádně obtížný úkol.

Jestli by v rámci kompromisu nebyl lepší ten NUC, ale bez krabičky - ovšem s přidaným ventilátorem strčit do něčeho takového: https://www.ledveci.cz/plastim-skrin-pp3011-200x300x130mm-pruhledna-dvirka--ip65/



Navíc by se k tomu dal přihodit i nějaký pěkný display: https://www.aliexpress.com/item/33057280844.html
Praktičnost neřeším, ale mohlo by to vypadat luxusně

Představuji si to tak, že po otevření průhledných dvířek by byl přístupný právě ten display (bývá dotykový), USB porty a zbytek by byl krytý plexisklem.

[RDa]

Proc resite pasivni a low power reseni? V prumyslu neni nad poradnej vetrak

[František Ryšánek]

Proc resite pasivni a low power reseni? V prumyslu neni nad poradnej vetrak

Souhlas - když je potřeba výpočetní výkon, chce to přiměřeně chladit.

Ale pokud stačí nějaký kozí dech, který není problém uchladit pasivně, tak je výhodou vyšší spolehlivost "solid state" řešení.