# Evaluation and Improvement of Internet Printing Protocol Based on HCPN Model Detection Method
## 3 Establishment of HCPN Model for IPP Authentication Process
### 0-RTT Authentication Model
#### 3.2.4 Bottom-Level Model  
The bottom layer was also called the method layer, which implemented two methods: verification and hash-ciphertext generation. These two methods were key supporting steps in the client and server authentication phases. Both communication parties implemented these two methods internally and obtained four method models: genSCiphers, VerifyS, genCCiphers, and VerifyC. In chronological order, the four events occurred in sequence: the server generated identity information; the client verified the server identity; the client generated identity information; and the server verified the client identity. The specific implementation details of these four processes are described below.  
genSCiphers: The server generated identity information, as shown in Figure 6. The message requesting the client certificate was stored in the place CertReq. The server certificate was stored in the place S_Cert. The hash values h1 and h2 were obtained by the two under the action of the server hash key ksh. Then, it was encrypted with the handshake key to form c1 and c2 (blue). The c1 and c2 were the raw materials for generating the server signature ss. The server signature completed the same process to obtain c3 (purple). In addition to c1, c2, and c3, the generation process of the server mac also required the participation of the server MAC key ksm. Then, we could obtain c4 (green) after hashing and encoding with ksh (server hash key) and hk (handshake key). Finally, the four hash ciphertexts were encapsulated and sent out.  
VerifyS: The client verified the identity of the server, as shown in Figure 7. First, the client decrypted (c1, c2, c3, c4) to obtain the corresponding hash values (h1, h2, h3, h4, respectively), and then calculated the hash values of the four messages received: certificate-request, certificate-verified, and finished. Finally, it compared whether the results obtained in the first two steps were consistent. If they were consistent, it indicated that the result was correct and the protocol was allowed to continue (green); otherwise, the protocol execution failed (red).  
genCCiphers: The client generated its own identity information, as shown in Figure 8. After verifying the identity of the server, the client received the reply to continue the protocol, generated the client certificate cc, calculated the hash value with the client hash key kch, and encrypted it to obtain c5. MSG3 contained the server identity information ciphertext (c1, c2, c3, c4), which was the raw material for client to generate signature and message authentication code. MSG3 and c5 generated client signature cs, which was encrypted by kch to obtain c6 (purple). Then MSG3, c5, and c6 were processed by kcm to obtain the client message authentication code cm, which was then encrypted to obtain c7 (green). The three hash ciphertexts were encapsulated and sent out.  
VerifyC: The server received and verified the client identity. This method was almost the same as VerifyS, as shown in Figure 9.  
Figure 6: Generate server ciphertexts.  
Figure 7: Verify server identity.  
Figure 8: Generate client ciphertexts.  
Figure 9: Verify client identity.