From 115edfe14ecd965304330f7310be65e795eb7da4 Mon Sep 17 00:00:00 2001 From: kasdimos Date: Thu, 21 Nov 2019 16:21:55 +0000 Subject: [PATCH] Update 'README.adoc' --- sec_iot_arduino_server.adoc => README.adoc | 196 ++++++++++----------- 1 file changed, 98 insertions(+), 98 deletions(-) rename sec_iot_arduino_server.adoc => README.adoc (96%) diff --git a/sec_iot_arduino_server.adoc b/README.adoc similarity index 96% rename from sec_iot_arduino_server.adoc rename to README.adoc index 9acd8f2..5d0a1d7 100644 --- a/sec_iot_arduino_server.adoc +++ b/README.adoc @@ -1,98 +1,98 @@ -Secure IOT (Arduino Server) ---------------------------- - -There are many ways to secure and authenticate a networking communication, but not all solutions will run on a microcontroller, where processing power and memory is a scarce resource. - -How does it work? -~~~~~~~~~~~~~~~~~ - -+Server -> the iot device that will receive the command+ - -+Client -> the command sender+ - - -. The Client connects to the Server. - -. [ Optional: The Client sends a predefined ammount of data for the Server to wake up. (Some libraries need the client to send first data, else they will not recognize that a connection was just made.) ] - -. The Server sends a challenge to be solved. - -. The Client send the solved challenge with the command. - -. The Server extracts the command from the response/solution, executes it [Optional: sends back the response ]. - -. [ Optional: The Client extracs the execution response from the Server response. ] - - - -Implementation -~~~~~~~~~~~~~~ - -Server + Client Requirements -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -- set the same initial data length (0-n) -- set the same hashing function -- set the same symmetric password - -Data -^^^^ - -. [ Optional: Client Sends: 1-n bytes (wake up packet) ] - -. Server: Sends Challenge (1-n bytes) - -. Client: Sends solved challenge ( Len(hash) bytes) - -. [ Optional: Server: Sends Response ( Len(hash) bytes) ] - - -Methodology -^^^^^^^^^^^ - -. [ Optional: The Client after connection, sends a predefined number of bytes. ] - -. The Server generates and sends a random number (bigger -> more secure) for each connection. -. The Client calculates and sends the HMAC of (random server data + command) using the shared secret password - -. The Server tries to find what possible command could the Client have sent -(calculates HMAC of random server data + possible command, using the shared secret password and compares them) -and then calls the corresponding function. [ Optional: The response of that function is then calculated -(HMAC of random server data + response, using the shared secret password) and sent to the Client. ] - -. [ Optional: The Client tries to find what possible response command could the Server have sent -(calculates HMAC of random server data + response command, using the shared secret password) ] - - - -Considerations -~~~~~~~~~~~~~~ - -Pros -^^^^ - -- Minimalistyc nor verbose -- minimal memory usage* -- minimal cpu usage* -- fast** -- authentication -- confidentiality -- replay protection - -*with the use of appropriate hashing functions - -**when a limited ammount of commands is used - -Cons -^^^^ - -- uses symetric cryptography -- is not designed to send multiple bytes (1 byte commands recommended) -- requires a random seed - -Proof of Concept -~~~~~~~~~~~~~~~~ - -Tested and fully working demo is attached! - -This demo was implemented on a pc (Node.JS Client) and an arduino pro mini with an ethernet shield (Server). +Secure IOT (Arduino Server) +--------------------------- + +There are many ways to secure and authenticate a networking communication, but not all solutions will run on a microcontroller, where processing power and memory is a scarce resource. + +How does it work? +~~~~~~~~~~~~~~~~~ + ++Server -> the iot device that will receive the command+ + ++Client -> the command sender+ + + +. The Client connects to the Server. + +. [ Optional: The Client sends a predefined ammount of data for the Server to wake up. (Some libraries need the client to send first data, else they will not recognize that a connection was just made.) ] + +. The Server sends a challenge to be solved. + +. The Client send the solved challenge with the command. + +. The Server extracts the command from the response/solution, executes it [Optional: sends back the response ]. + +. [ Optional: The Client extracs the execution response from the Server response. ] + + + +Implementation +~~~~~~~~~~~~~~ + +Server + Client Requirements +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- set the same initial data length (0-n) +- set the same hashing function +- set the same symmetric password + +Data +^^^^ + +. [ Optional: Client Sends: 1-n bytes (wake up packet) ] + +. Server: Sends Challenge (1-n bytes) + +. Client: Sends solved challenge ( Len(hash) bytes) + +. [ Optional: Server: Sends Response ( Len(hash) bytes) ] + + +Methodology +^^^^^^^^^^^ + +. [ Optional: The Client after connection, sends a predefined number of bytes. ] + +. The Server generates and sends a random number (bigger -> more secure) for each connection. +. The Client calculates and sends the HMAC of (random server data + command) using the shared secret password + +. The Server tries to find what possible command could the Client have sent +(calculates HMAC of random server data + possible command, using the shared secret password and compares them) +and then calls the corresponding function. [ Optional: The response of that function is then calculated +(HMAC of random server data + response, using the shared secret password) and sent to the Client. ] + +. [ Optional: The Client tries to find what possible response command could the Server have sent +(calculates HMAC of random server data + response command, using the shared secret password) ] + + + +Considerations +~~~~~~~~~~~~~~ + +Pros +^^^^ + +- Minimalistyc nor verbose +- minimal memory usage* +- minimal cpu usage* +- fast** +- authentication +- confidentiality +- replay protection + +*with the use of appropriate hashing functions + +**when a limited ammount of commands is used + +Cons +^^^^ + +- uses symetric cryptography +- is not designed to send multiple bytes (1 byte commands recommended) +- requires a random seed + +Proof of Concept +~~~~~~~~~~~~~~~~ + +Tested and fully working demo is attached! + +This demo was implemented on a pc (Node.JS Client) and an arduino pro mini with an ethernet shield (Server).