so there is two step : how to hande the auth flow --> /login, put your phone number, send to serve server check if phone number is in record, true --> send otp, route : /device_registration?public_key=...&device_id=... /device_verify?device_id=...&signed_message=... /device_verify_user?user_session_id=... /device_send_mathc_result? /login /singin /otp_verify /rank /update_profile?session_id=... /search?user_name=... 1. Open Ligue Inc first register the http server with the /device registration endpoint + we generate a single unique cryptographic key pair for the server and store private key securly 2. then we setup the factory where we assemble nd flash the open ligue glt device : a master device which will communicate with the ser and server + sensing goal and a slave devic since in football there is two goal, that the sole job is glt and seding it to the master, each pair of device are associated, meanning that there not interchangable there are visual marker for user to easy recognise a pair. So on the factory we generate a cryptographic key pair for the master device along with a unique device id, that we hardcode inside the firmware (private key and id), then we send the device id and public key on /device_registration?device_id=...&public_key=..., and we also hardcode the server public key inside the firware, we also generate a key pair for the slave and hardcode the public key of the slave inside the master, then we flash -> secure boot -> flash encryption. *why do we generate a key pair ? you will see later when our device will cmmunicae with the server *why flash encryption ? TO ensure the private key are not seen, so anyone can usurpate a device, tis for trusting the hardware We then hardcode a static ip to the master device (the same for all open ligue glt devices) then we ship both device, factory step finished. 3. User recieve its Open ligue Glt, --> the master and the slave : lets see in more details their potential hardware composition (not defined yet) : the master has realteck wifi coprocessor, which can handle 32+ concurrent wifi connection, has also its own tcp ip stack for http, ws --> communicating inside the pwa to the device p2p. there might be led indicator for feedback on local handshake*, and its connected to the velostt sheet, the electronics has a protective layer,sensor part consist of two tube of n centimeters to which is hang a elastic fabric to which is stiched the velostat grid that fall naturraly (this ensure no false positive due to stretching the material, and the tube ensure this can be deployed on most of terrain the slave is just regualar esp32 with the velostat sensing module and led indicator the user press on on both device, the local handshake can start : they both start EspNow encrypted tunnel, the master then send a challenge to the slave, the slave sign it the master verify and if singature is valid, the master start wifi session & toggle led indicator (sssid broadcast) and the ready check phase start user can now see the the ssid of the device and maually connect to it. then start tcp connection with the device http server --> start of the device auth process : the user send a challenge to the device, the device sign it, send it to the server by exploiting user cellular connection (!!! crucial --> users must have 4g/5g to use the software) and send it to server to /device_verify, then the server will return true of false if true the user (client side code (!! important, the client side code must be authentic, hashed, no xss) client sode code send its session id to the trusted hardware, then the device sign it and send it to the server, to ensure no ecclipse attack the server sign the response and send back the client will then then send the response back (not just eh verification but the whole user profile to the device if he want to register to this game the device will verify the singature of the server by using the hardcoded public key we setup before if true register the user for this game this process happen for each user connecting : --> verify the hardware, then verify the user the device now keep an array of registerd user end a websocket connection is opened between them and the server we exploit os split routing to ensure that packet destined to the device are correctly routed, and packet destned to the wlan **!!! but you forget that the browser will not allow an http connection with the device ? how do you setup tls for a iot device ? either we buy a domain that will redirect to the device private ip, and perform acme on it at factory stage now to start a game their must be minium 6 player and max 22 user can signal ready, once enough player are ready timer start at the end of the timer, it stop accepting firther connection and for each ready player it randomly split team for each player calculate potential elo win/loss --> with certified data he got from the serve --> in the mean time a feedback indicator are showed to player --> once finnished start kickoff timer end send the data to users after the end of the timer, it start the match timer which is constant across the league, and start recording goal --> send signal to slave for recording goal when the slave get a goal it just transmit to the master (always signed) the master via websocket update score on user views, at the end of the game, it sign the result and elo calculation, sending it to the server --> the server check update and send confirmation (always singed) --> in the mean time users have a loading spinner --> if true, they got final result view, and their prfile and rank is updated impossoble problem : the hacker cant upload a new firmware on the device to currupt it (which will do nothing since it dont have acess to th server) even making a malicious copy cant do anything since his device will need the private key in order to communicate with the server and transmit false claim what he can do is use phyisics to virutally grant himself goal, applying current to send false positive, but thats at the physics level we cant do anything about that, just, user are smart --> we can add an oled screen that show goal, and user hav amind and know how to count if they see, something dont add up and signal it --> so you can signal and we will handle confict --> also for this to happen you must trust the user hardware, if i say that for this game we will use our for other obvious cheating like taking that ball on hand, making obvious foul, this is so obvious honest player know who made the cheat and can beat him up for malicious coordination of user trying to make fake game, they dont need high end technology to modify the hardware etc, they can just agree to cheat, but in order to play they need account and account are tied to phone number which are harder to autmate, meanning the user sacrifice his rank on the platform for somebody else, for other trying to boost their score by player virtual game they will have to spent time, they will loose a lot of time, this attakc is not practicable at scale for those who will just want to virtually player, its possible, just need one user who will collect session_id of the other (which is full account acess, including phone number..., so not very idea for an attacker), and send them, using a lot of device, since the glt will only accespt one session per mac adress, but with mac adress randomisation --> no since they need to disconnect and reconnect, -> if when you disconnect your wipped out this attakc is ont possible without bringing a lot of hardware, again, they will be bottlneck by the time it take to complete a full game, with enough user on the app --> and again, one will purposfully loose for other to win. what positive is that a user cant fake its ession id, we ensure via server signature that all registrated user are in fact registrated into the app next is how to handle tcp and wifi disconnect, player who quits in ready, check, in game...