There are enough buzz around about M2M data security and it is not the place for survey or study. So, let us directly dive to the point for developers.
Here we shall be discussing about possible Relay attack and Replay attacks.
I described the M2M messaging in https://esp8266mesh.wordpress.com/push-notification-service/
If you have not followed it, just go through it and come back again.
All the messages are protected by 32byte Keys and no one can interfere to your private system, until your keys are leaked. Once, your keys are leaked (and you have realized it :P), the only option left it to change the KEY by API.
But, updating of Keys to all devices in the field is much more hectic. So, let us here discuss about the possible option to keep your keys remain private.
You never know, who will be looking over your network. And its pretty easy to sniff your data. Well, we all know SSL and TLS are absolute protection, till now, but same time, we all aware the complexity of managing the secure layer in device as well as server side when we are talking end-to-end communication.
The API described at https://esp8266mesh.wordpress.com/push-notification-service/ are RAW TCP commands and wireshark will show all the fields in plain text, and there is a way to get the KEY details and any one (with black hat) can MAKE his own packet (Relay attack) using your KEY and can collapse the system. OK, the another easy option is, not to modify anything, is the packets are just replayed at later time (Replay Attack), the same device behavior of the IoT device may be expected.
How can we protect it? We shall start Symmetric key based security., first.
Replay Attack:
First think about a Replay Attack. The “command” or “data” packet can be “copied” or “cloned”. And those cloned data may be replayed later on to regenerate same Result.
The method described below eliminates the possibility of Replay Attack, completely. Here, we hall be generating a session key for each client. And those session keys are based on a Random number sent by Server which can not be altered by client (attacker). Hence, although, data may be copied or same, but the session-Key will be different for all clients or session.
Let me use the very basic concept of Mutual-Authentication (I-Auth+E-Auth), by which, the actual KEY will be never exposed over the network and always we shall be using a derived key or session key. So, the KEY will be dynamic for every session, every device and all are derived from same key. Well, real KEY can not be mathematically derived from derived-key.
Let us see, how it is being done:
Device Verification: The client will be verified by server
1. You have the KEY, let us call it KEYSEC. Keep it secret. Only server knows it and you (IoT device) will be knowing it. It will never come out-side device at plain-text.
2. At connection initiation with PushServer, Server will throw the Random Number KEYRND
3. Hash after Concatenation KEYSEC and KEYRND. It will generate Session key- KEYSES . Use the session key for rest of all commands during the session.
Interestingly, all the client will get different Random number and the Session Key(KEYSES) will be different. So, even if the KEYSES is in plain text and copied, but it can not be used by anybody or any other client to connect with Push server.
Server Verification: The Server will be verified by Client (Device)
4. Let us talk one step ahead. The Server authentication. Is the Server valid? And authorized (knows your key?)? To do that, we shall perform a reverse test. The client (IoT device) will send a Random no (let us call it KEYRNDDEV). Server should return the HASH(KEYSEC+KEYRNDDEV), and client (IoT device) can verify it. If calculated Hash and sent (by Server) are same, device can ensure that the Server is genuine.
So, how the API will work?
Activate Session Key based communication. Client authentication by dynamic Session
Get Challenge (Client/Device Auth) from server
STCP::ACTIVATE:
Returns: (Server sends the challenge)
OK:
Key Derivation (at Client side):
SESSION_KEY= HASH_MD5(KEY+RANDOM_NO)
Use Session_key for rest of API as it is.
Get Challenge and Get Response (Client/Device Auth+Server Auth)
STCP::ACTIVATE::
Returns:
OK::
RESPONSE verification (at Client): RESPONSE= HASH_MD5(KEY+RANDOM_NO) Key Derivation (at Client side):
SESSION_KEY= HASH_MD5(KEY+RANDOM_NO)
Use Session_key for rest of API as it is.
De-activate Session Key based communication.
STCP::DEACTIVATE:
Returns:
OK:STCP_DEACTIVATED
Use Normal key for rest of API as it is.
Your IoT device is protected from Replay Attack, 100%.
04/03/2017
Now what about Relay Attack??
If there is a man in middle,and it simply relays the session (with cloned Key) with modified data? Oh! Your device will be screwed up.
Relax! Here is the solution.
I know, probably, you will not use my API, but what is the harm to know stuffs 🙂
In typical Relay attack protection, Time Stamp of client is used. Here, we cant do (or do not intend) because of less resource availability and NTP. Rather, we shall use “nonce” or Random Data, once sent from server.
Let us consider “DATA” too, as a parameter of session Key generation function. So, here we are talking about a Dynamic session key where KEYSES= Hash(KEYSEC+RND+DATA). And every-time,with every packet sent to SERVER, the KEYSES will vary based on DATA. Both integrity and secrecy (of secret Key) will be maintained.
Is not exciting?
OK, let us see the API list:
Activate Dynamic-Session Key based communication.
Get Challenge (Client/Device Auth) from server
DSTCP::ACTIVATE
Returns: (Server sends the challenge)
OK:
Key Derivation (at Client side):
DYN_SESSION_KEY= HASH_MD5(KEY+RANDOM_NO+DATA)
Use Dynamic_Session_key for rest of API as it is.
Get Challenge and Get Response (Server Auth)
DSTCP::ACTIVATE:
Returns:
OK::
RESPONSE verification (at Client): RESPONSE= HASH_MD5(KEY+RANDOM_NO) Key Derivation (at Client side):
DYN_SESSION_KEY= HASH_MD5(KEY+RANDOM_NO+DATA)
Use DYN_Session_key for rest of API as it is.
De-activate Session Key based communication.
DSTCP::DEACTIVATE
Returns:
OK:DSTCP_DEACTIVATED
Use Normal key for rest of API as it is.
Now, your Device is fully protected from Relay Attack and Replay Attack.
Cheers!
What next?
Ready to move with Hash-chain?
Keep in touch for further level of security updates..
esp8266 mesh WIFI 