## Solution
### Mcspi
#### 3.1.1 Intercept and Parse Message  
We first use a man-in-the-middle proxy to intercept the security protocol messages. Then, intercepted messages are parsed through identifying message symbols, for example, end symbols, delimiters, and connectors, to locate \(T_{n}\) in the original protocol messages.  
Definition relation \(A\): \(\mathrm{T}_{n}\in\mathrm{B}_{n}\in\mathrm{P}_{n}\), \((\mathrm{T}\
eq\varnothing,\mathrm{B}\
eq\varnothing,\mathrm{P}\
eq \varnothing,n\in N*)\), where \(P\) is a set of protocol message pieces, \(B\) is a set of protocol blocks, and \(T\) is a set of protocol message tokens. The protocol message consists of the message pieces, which are composed of protocol message blocks. The message block consists of message tokens.  
First, security protocol implementations are scanned to extract message symbols, and then, the frequency of the extracted message symbols is computed. After that, these symbols are sorted from high to low frequency to be identified. Finally, message pieces, message blocks, and message tokens are generated.  
In general, message symbols mainly include message end symbols, delimiters, and connectors. A message end symbol such as \"\(\backslash\)r\" or \"\(\backslash\)r\(\backslash\)n\" indicate the end of protocol messages or message pieces. A delimiter usually delimits different fields and message pieces of protocol messages. The common delimiters mainly include the \" \", \"\(\backslash\)\", etc. A connector connects two or more message tokens, for example, \"?\", \"&\", and \"=\", etc.  
We take a message of HTTP 1.1 as an example to illustrate the parse of a protocol message in Figure 3.  
Here, token parse method by identifying message symbols is drown in (a), and the generated tokens after parsing protocol message in (a) are shown in (b).  
The procedure consists of six steps:  
1. Identify \"\(\backslash\)r\(\backslash\)n\" symbols to generate message piece \(P\).
2. Parse message piece P through identifying space symbol \" \" to produce message token \(T_{1}\) and message block \(B_{1}\).
3. Parse \(B_{1}\) by identifying delimiter symbol \"/\" to generate message token \(T_{2}\) and message block \(B_{2}\).
4. Parse message block \(B_{2}\) through identifying message connecting symbol \"=\" to generate message blocks \(B_{3}\) and \(B_{4}\) and message token \(T_{7}\).
5. Parse \(B_{3}\) and \(B_{4}\) by identifying message connecting symbol \"?\" and \"&\" to produce message tokens \(T_{3}\)-\(T_{6}\). Note that \(T_{3}\) cannot be parsed into \"_login_\" and \"_jsp_\".  
Figure 2: The idea of the Message Construction to Security Protocol Implementation (MCSPI).  
All of the message tokens \(T_{1}\)-\(T_{7}\) in (b) in Figure 3 locate the message token(s) which would be replaced by matching with the original output of traced cryptographic functions.  
In order to efficiently parse the intercepted messages, some messages are parsed at the block level and other messages are parsed at the token level. For example, in Figure 3, \"_127.0.0.1_\" represents an IP address so it cannot be parsed into message tokens as \"_127_\", \"0\", \"0\", \"1\". If it was parsed into tokens as \"_127_\", \"0\", \"0\", \"1\", it might cause some bad effects, such as the waste of computing resources and the failure of message token location of parsed protocol messages. For instance, for the message shown in Figure 3, the field of \"_127_\" needs to be replaced with the reconstructed output. If the reconstructed output of traced cryptographic primitive implementation is \"_192_\", it will be used to replace \"_127_\" in the protocol message. After that, the IP address becomes \"_192.0.0.1_\". Hence, the service connection between client and server will fail and the message token cannot be successfully located. To avoid it, the special message field or message pieces cannot be parsed at the token level.