UbiPush:Hash Chain: Block Chain-I

05/04/2017
I took some time to start this thread. Rather than users and readers, it was a self chanting towards the future prediction.
I dont know, what will be next after this Block-chain, but, till now I am seeing a bright Sun behind the foggy day coming ahead!
Let me start from Hash-Chain.
In M2M the data propagates again and again and again.
Let us preserve the tail through trails. I shall be eating the stuff from an edge and if you are with me, you will be learning stuffs as I do believe “Understanding by Doing”
I believe, HASH is the keywords of message train in a nut-shell. Let us try to preserve it through out the process.
What about the new definition of Session Key as:
In session 1 (The same client has established the first connection to Server):
SES1KEY0=HASH(KEYSEC+DATA)
SES1KEY1=HASH(SES1KEY0+DATA)
SES1KEY2=HASH(SES1KEY1+DATA)
………………………
SES1KEYn=HASH(SES1KEY(n-1)+DATA)

In Session 2 (The same client has established a new connection to Server):
SES2KEY0=HASH(SES1KEYN+DATA)
SES2KEY1=HASH(SES2KEY0+DATA)
SES2KEY2=HASH(SES2KEY1+DATA)
………………………
SES2KEYn=HASH(SES2KEY(n-1)+DATA)

So, what exactly we are achiving by all those shits?
1. We are no more using the KEYSEC after first transaction. So, its not necessary to store the KEYSEC in ROM/Flash in Device or secure memory. It can be initialized at factory level in RAM before dispatching the IoT device (Machine).
2. We are keeping a trail and tracking the previous data transfer in both Machine and Server. It will protect any security breach (Relay Attak and Replay Attack)
3. The HASH algorithm will be simpler to calculate.
4. The Device needs to store current Session_KEY and it will be different for all devices (although all are derived from same KEYSEC). So, the KEYSEC will be virtually immutable.
5. We are no more using Random Number. Will save transaction overhead, calculation overhead. Please note the interesting point: The importance of Random no was to make session key as dynamic (as KEYSEC and DATA may be static). In the HASH-chain, the KEYSEC became a dynamic (KEYSEC=SESnKEYn) , which is the catch!

I will start releasing API, once the concept is framed more firmly 🙂