# Extracting the Secrets of OpenSSL with RAMBleed
## 5 Analysis of OpenSSL and Apache
### Investigating Whether Physical Memory is Allocated for Secret Information
#### 5.2.3 Identifying the Writing of Prime Numbers in Memory  
In this section, we present the method used to identify the process that allocates physical memory to \(p\) and \(q\) and the results of the analysis of the server process that performs the TLS handshake with the client. The value of Apache's MinSpareServers was set to one to simplify the analysis. The GNU project debugger (GDB) was used for the analysis. An overview of the the analysis method is provided below.  
First, we started the Apache server and performed a TLS handshake once with the server-child process. Next, we identified the virtual addresses of \(p\) and \(q\) from the virtual memory dump of that process. A new child process was created because the number of idle child processes was less than the MinSpareServers value. The new child process has not yet performed the TLS handshake. We attached to this process with GBD and set watchpoints at the the virtual addresses of \(p\) and \(q\). In this state, the process that was stopped for the GDB to be attached was restarted, multiple TLS requests were sent externally, and the attached process received one of the requests. The process that received the TLS request stops when it accesses the watchpoint during execution of the TLS handshake. Following that, we verified the data indicated by the watchpoint. When that data are neither \(p\) nor \(q\), we restart the process. This operation is repeated until \(p\) and \(q\) appear in the virtual memory at the point indicated by the watchpoint. Finally, we identified the process that accessed \(p\) and \(q\) in OpenSSL by observing the stack trace at the time \(p\) and \(q\) appeared in memory.  
The analysis revealed that in the TLS1.3 handshake, \(p\) and \(q\) are written to the physical memory page in the process of composing the CertificateVerify message sent from the server to the client. The CertificateVerify message is used to prove that the server possesses the private key corresponding to the public key and includes a digital signature created by the private key of the server. We discovered that access and physical memory allocation to \(p\) and \(q\) occurs in the OpenSSL function that is responsible for the digital signature process. Moreover, rather than allocating physical memory to \(p\) and \(q\) simultaneously for access, they are written to pre-allocated physical memory pages during the TLS handshake. Furthermore, after the server-child process executes the TLS handshake, \(p\) and \(q\) remain written in the physical memory allocated to the child process for as long as that child process exists. However, when the number of child processes on the server exceeds the MaxSpareServers value, the server-child processes are destroyed by the parent process, and \(p\) and \(q\) may be purged from the memory simultaneously. Therefore, it is necessary to maintain communication with the child process to keep \(p\) and \(q\) in the physical memory page.  
Considering the above analysis, an attacker can cause \(p\) and \(q\) to be written to the target page by releasing the dummy pages and the target page before the TLS handshake is executed. Additionally, these can be read using RAMBleed by maintaining communication with the server-child process because \(p\) and \(q\) remain in the target page after the TLS handshake is executed.