Mutual or two-way-authentication

In this method, both parties authenticate each other without exchanging private keys. This method uses single-use private keys for exchanging confidential information. Private keys will be valid just for that one time. Sounds complicated? Let us simplify it with an example:

Suppose Bob and Tom want to exchange critical information, such as the password to their bank accounts or the key to the company database key in a telephone conversation. Can Bob and Tom, who have never met nor heard each other before, authenticate each other's identity? Most importantly, how can they prevent the tapping of their phone calls by bad actors?

 

The solution is mutual authentication, but how does it work?

Let us start with a simple example. In the phone conversation, Bob randomly chooses a number and tells Tom about it. To make it easier, we will name the random number, A. following the selection, Bob asks Tom to convert the number A to number B, with the employment of a unique formula only they know of ( the formula is provided to both parties by the company).

On the other hand, Bob also puts the random number A in the same formula; coming up with a number called C. If number B, which is the result of the operation run by Tom, is equal to number C, then Bob can trust Tom.

Nevertheless, Tom still does not trust Bob, so he repeats the same process as Bob. Likewise, he tells Bob of a random number A, asking him to convert it to number B, using the secret formula only the two know. Tom converts A to C, using that same formula now if C is equal to B, it means Bob is also in possession of the formula and trustworthy.

It is only natural that the code for converting A to B, must be a complex one; how much more the degree of complexity in the formula will be, it is less likely for the third party listening to the conversation to figure it. Selecting a bigger random number will also increase security.

Exchanging confidential information

Now that Bob and Tom have authenticated each other, can they easily exchange information? No! A third person is listening to these conversations, awaiting just the sort of information. How should Bob and Tom speak so that the listener does not realize? The answer is using the temporary formula generated using Bob and Tom's random numbers and the previous confidential formula.

While Bob and Tom choose a different random number every time, the earlier formula alters. Using the single-use formula, Bob and Tom can convert information into code and exchange it with each other. Applying the method, Bob and Tom swap fixed, specific information without the third-party having a hint about it.

Let us challenge the proposed solution: George is listening to the conversation.

Suppose a third person named George is also listening to the conversation. George calls Tom right after the phone call ends, claiming he is Bob and has forgotten the bank password he's been given. He will ask Tom to give the password to him again, providing Tom with the number Bob had given to him in the previous conversation.

He will give the same number Bob had given to Tom since he supposes this number is the password. Tom will convert the number using the stated formula and let George know about the result. Is the problem solved already?

No, because Tom does not truly trust the caller and wants to challenge. George will fail to provide him with the result number since he does not have the formula. Supposing the code would come with the previous number, Gorge will give Tom the answer Bob had previously provided.

But the formula produces a different number if the input is not the same, from which Tom is precisely aware. Tom will immediately hang up after finding out that he does not know the formula and must not be Bob.

How Prokey use it to authenticate hardware wallet?
 

Random numbers: As we said before, the larger the used random numbers, the higher the system security. We recommend keys between 64 and 256 bytes. In Prokey, the length of a random number is 128 bits, which means the average number will be as big as 3.40 × 10³⁸.

Encryption algorithm: It is possible to employ various algorithms, including AES, 3DES, DES, and many others. In prokey we apply an AES algorithm featuring a 256 bit key for encrypting confidential information.

Keys: 

Keys are the secret formula between Bob and Tom. You can possess one or a series of keys. The more keys you own, more security you will guarantee for yourself. Employing an algorithm, you can derive and generate secondary keys from a stable source.

We, in Prokey have employed an innovative method for generating secondary keys. The technique works in a way where every secondary key is related to the random numbers. For creating this sort of a key, we hired a non-returnable SHA256 algorithm and a Seed. In the proposed method, random numbers determine how many times there is a need for a hash.

A real-time example executed in Prokey:

In this example, D is the abbreviation for Prokey Device, S indicates Server, and D and S are trying to authenticate each other:

Server	Prokey Device
Generates a 128bit Random Number and sends it to device, we call it RNDS Server Sends RNDS
	Device Received RNDS Device generates KEYS based on RNDS and Seed Calculate EncRNDS =AES256(RNDS) To reduce transaction, here device also generates a 128bit Random Number that we call it RNDD Device Sends EncRNDS & RNDD
Server received EncRNDS & RNDD Server Generates KEYS based on RNDs Calculate tmp = AES256(RNDS) Terminate if tmp != EncRNDS Server Calculates KEYD Calculate EncRNDD =AES256(RNDD) Server Sends EncRNDD
	Device Received EncRNDD Device Generates KEYD based on RNDD Calculate tmp =AES256(RNDD) Terminate if tmp != EncRNDD Device Generates SessionKey based on RNDD & RNDS & SEED Device will send HASH(HASH(SessionKey))
Server received HASH(HASH(SessionKey)) Server Generates tmp based on RNDD & RNDS & SEED Server terminates if HASH(HASH(tmp)) != SessionKey Server Sends ACK
	Device Received ACK All the rest data will be AES256 encrypted using Hash(SessionKey)