This is original protocol :

$($Diagram as image uploaded$)$

For the above$-$mentioned scenario, we propose an authentication protocol that consists of two phases, as depicted in Fig. $8.$ In the enrollment phase, mea$-$ surements MDID :$=\{$MC$0,...,$MCn$\},$ each corresponding to a memristor cell from C$0$ to Cn of a smart device with an identifier DID, are captured and transmitted to the IoT Hub over a secure channel, e$.$g$.$ by establishing a direct connection between the IoT Hub and the device in a controlled environment without any other network connection. Each cell is measured with multiple fre$-$ quencies F :$=\{$f$0,...,$fn$\}$ and amplitudes A :$=\{$a$0,...,$an$\}.$ The IoT Hub stores the model ModelDID of the smart device learned by the manufacturer along with an identifier DID. In the highly unlikely case that the CNN model fails to be produced for a particular DID after a few attempts, this DID shall not be used. Also, a public key is transmitted to the smart device, which is used in the next steps of the protocol. There, lightweight algorithms using elliptic curve cryptography are used.

In the authentication phase, a challenge$-$response protocol is executed. First, the smart device sends a challenge with its identifier DID to start an authentication request. Here, $||$ describes the concatenation of the message, and the first italicised segment, e$.$g$.,$ AuthRequest, is an identifier, allowing the IoT Hub and the device involved to identify and parse the relevant messages correctly. The server responds with a challenge containing a device ID DI$$D$,$ a nonce N$,$ a cell ID CID, an amplitude a$,$ and a frequency f$.$ N is used to prevent replay attacks and can be implemented as a continuous counter or a random number. The IoT device first checks if the requested device ID$,$ DI$$ D $,$ is equal to its own, and then measures the cell CID by applying the frequency f and amplitude a to it$,$ resulting in a measurement MCID. Afterwards, a message consisting of the DI D $,$ the previously sent nonce N $,$ and the measurement MC I D is encrypted using the previously shared publicKey, and sent to the IoT Hub. Only the IoT Hub can decrypt the message using its privateKey. The server checks if N is fresh, and chooses the right model, ModelDID $,$ based on DID. If the CNN can classify all measurements correctly using ModelDID $,$ a$,$ and f$,$ the IoT device gets authenticated, otherwise it gets rejected. After a number of unsuccessful authentication requests for the same DID, the use of that DID may be disabled.

And this one is derive from that:

First we have set$-$up these parameters;

Public, Private key pairs

$1)$ Enrollment Phase: $-$ First Device will send its Device identification $($DID$)$ to Server

$-$ Server will send its Public key

$-$ PUF produce a "golden" response with challenge

$-$ Device $($D$)$ will send "golden" response with

DID $+$ Device Challenge $($C$\_$DID$)$ encrypted with

Device Public key

$-$ Server will take this $($C$\_$DID, s$,$ DID$)$ Pub$\_$DID

Decrypted with its private key and store it$.$

$2)$ Authentication Phase: $-$ Device will make an authorization request $($Authreq$,$ DID$)$

$-$ Server will go to Database get relevant challenge $($C$\_$DID$)$

know the relevant "golden" response, create Nonce $($h$)$

$-$ Server Encrypt this challenge and Nonce and send

to Device

$-$ Device will decrypt this challenge with its private key.

$-$ Device will create response $($R$)$ and with Nonce send

to server back.

$3)$ Hamming Distance $($HD$)$ is the noise.

We are comparing "golden" response $+$ noise $(+$HD$)$ compare with Response $($R$)$

so let's "old proven" is okay,

So the according to original and new protocol the list of points should be answered:$($please do not use any Ai$)$

$*$ Overview of the Original Protocol

$*$ Rationale for Modifications

$*$ Description of Modifications

$*$ Impact of Modifications