POST upload

Způsoby nahrání uživatelského programu do SDS přes web-POST

V současné době je implementace provedena pouzde do SDS-BIG-512 a SDS-STSW-512.
V budoucnu bude stejný protokol implementován i do dalších SDS.

Výchozí způsob nahrávání uživatelských řidících programů (SDSC, FULLC) a dalších prvků (UserWEB project) do SDS, je prováděn přes proprietární UDP protokol, skrze výrobcem dodávanou aplikaci (SDSC.exe, FULLC.exe, SDSLOAD.exe).

Toto řešení ale nelze vždy všude využít - čast v prostředí kde je přísný firewall co zahazuje UDP komunikaci, nebo při konfiguraci SDS které jsou za neprostupným NATem. Důvodů může být mnoho.

Jako vhodnou a bezpečnou alternativu nabízí SDS možnost nahrání své konfigurace a řídícíh programů (a UserWeb projektu) prostřednictvím autorizovaného HTTP POST.

Pozn. Speciální firmware pro BIG512 bude poskytovat HTTPS POST - nicméně protokol API atd. uvnitř komunikace s webovém serverem v SDS bude stále zcela stejné..

Co se dá přes POST nahrát

1. [/changeip] Konfigurace IP - viz dále

2a. [/newfullc] FULLC Program - soubor .FCB

2b. [/newsdsc] SDSC Program - soubor .SCB

3. [/newuserweb] UserWEB Projekt - soubor .UWB

Tyto prvky jsou vybrány tak, aby bylo také možné plně skriptovat nahrávání SDS, bez nutnosti uživatele použít GUI a ručně klikat atd.

Text v hranatých závorkách je příkaz, ten se musí zapsat za POST - tedy např. "POST /newfullc HTTP/1.1<cr><nl>" (první celý řádek hlavičky)

Pozn. Soubory .FCB a .UWB vygenerujete pomocí aplikaci FULLC.exe.

Zabezpečení

Dle průmyslového standardu, je vždy potřeba se, jako klient, vhodným způsobem autorizovat vůči serveru. Metoda také musí odpovídat průmyslovému standardu a být plně auditovatelná uživatelem (proto je i zde popsána). K dispozici jsou i vzorové příklady (např. aplikace se zdrojovým kódem).

SDS tedy nejprve, pro každé jednotlivé spojení, vyžaduje autorizaci klienta.

Pro každé spojení SDS vygeneruje unikátní 256bit SALT, který není nikdy opakován (využívá se HW RNG v SDS), a je platný jen po dobu tohoto jednoho spojení (pro jeden příkaz).

Klient tento SALT přijme, provede s ním kryptografické operace (průmyslový standard saltování hesla: dvojitá SHA-256 operace).

Stejné operace provede i server u sebe, a jakmile klient pošle serveru svůj výsledek, server provede ověření (porovnání svého a zaslaného výsledku).

Pouze pokud klient zašle správný výsledek, znamená to, že klient zná identické heslo, jaké je nastaveno v SDS - a tedy může se pokračovat. Jinak je spojení ukončeno.

Přenos na úrovni komunikace s webovým serverem není šifrován. Pokud je potřeba úplné šifrování, je využit TLS (nižší OSI7 vrstva) - pouze speciální firmware pro BIG-512.

Soubory .FCB a .UWB jsou zabezpečeny už při jejich vytvoření, takže jsou chráněny nejen při přenosu tímto protokolem, ale i v klidu např. na disku (zabezpečení je šifrováním a kontrolním podpisem detekujícím jakoukoliv změnu). Proto není potřeba je dodatečně při přenosu šifrovat (mimo eventuální TLS což ale genericky šifruje celý HTTP provoz, nicméně klient vždy odesílá soubory 1:1 tak jak je čte z disku - o tento detail mi teď šlo).

Detaily

Probíhat může vždy jen jedno spojení. Je to logické, pokud se nahrává program, nelze v prostředku nahrávání začít posílat jiný (musí se počkat až se původní činnost dokončí).

V takovém případě server informuje klienty v nových spojení že je BUSY a spojení uzavře. Je na klientovi počkat a zkusit znovu (za vhodný čas).

Protokol

Jedná se o standardní komunikace s webovým serverem. Na straně klienta ji lze realizovat libovolným způsobem.

Klient otevře spojení, pošle HTTP hlavičku s POST (a příkazem), a pak provede autorizaci, a (pokud je autorizován) tak provede kroky k nahrání programu či aktualizaci konfigurace.

 HTTP POST

 client                                        <->         server
 -----------------------------------------------------------------------------------------------------------------------------------
 [1] open TCP connection to HTTP server               <accept>

 [2] send POST header + command name in URI

   POST /command HTTP/1.1<cr><nl>
   Host: 192.168.4.250<cr><nl>
   Content-Length: 12<cr><nl>
   <cr><nl>
   NoncePlease<cr><nl>


                                                      [3] response from server

                                                        Nonce:HEXSTRING(32B)<cr><nl>

                                                      or

                                                        Busy:CLOSING<cr><nl>    -> and close the connection


 [4] compute SHA-256 HASH for SALTED-PWD

 [5] send hash result to server

   Auth:SHA-256:HEXSTRING(32B)<cr><nl>


                                                      [6] response from server

                                                        Auth:REJECTED<cr><nl> -> close connection

                                                        Auth:CONTINUE<cr><nl>


 [7] if Auth:CONTINUE,
     client sends:
      START:START<cr><nl>

                                                      [8] server starts its internal process (program memory erase)
                                                          (this takes up to 45 seconds ! client has to wait.)
                                                          once done, server sends:

                                                        Erased:ReadyToWrite<cr><nl>

                                                        or

                                                        Deny:UnableToEraseOrWrongContentLen<cr><nl>


 [9] if client gets: "Erased:ReadyToWrite"
     and the command requires further data transfer,
     then send binary data
     (otherwise, just wait for [8])

   raw binary data, do not encode !

   note. Content-Length -> exact size of 'raw binary data'
   (or, if no data are to be txed, (always) send Content-Length with 0 as value)


                                                      [8] once all data are received, send:

                                                       Done:result<cr><nl> -> and close connection


----------
notes.

 HEXSTRING(32B) = 64 characters, HEX16 encoded (each byte = 2 chars), fmt: 32 x "%02X" , no spaces

 Done:result -> 'result' is textual printout of a uint32_t number

Vzorový záchyt

TODO Wireshark

Autorizační mechanismus

TODO komentář

 HASH FUNCTION:

  Nonce -> unqiue 32 bytes (represented as 64char hexstring) originated on server
           (an always-random number, tied to each single TCP connection only - once closed, Nonce is invalid)
           (new nonce is generated for every each new connection)

  SHA-256 HASH result -> process:
   1. Calculate SHA-256 hash of 'password'                     -> resultA[32]
   2. Convert resultA[32] to a 64 character string             -> textHashP[64]
   3. Take 'salt' as 64 character string (exactly as it come)  -> textSalt[64]
   4. Concatenate textHashP with textSalt                      -> forHash[128]
   5. Calculate SHA-256 hash of string forHash[64]             -> resultH[32]
   6. Convert resultH[32] to 64 character string               -> transmitH[64]
   7. Send transmitH[64] to server

  Server and client does the same exact process, and if transmitH[64] is equal on both sides, server allows the client to continue

Ukázky autorizace

TODO příklad s interními stavy

COMMAND: /changeip

TODO text

COMMAND: /newfullc

TODO text

COMMAND: /newuserweb

TODO text