## 4 mobiDOM Design
### Malware Detector
#### 4.1.1 Enabling Stealthy Communications between The TAPp and MDetector  
The TAPp and the MDetector will communicate with each other through the CA stealthily. In particular, the TAPp will issue commands, and the MDetector will execute the commands and send back responses. For simplicity, we define three basic commands for the TAPp to control the MDetector:  
* _START_: This command will request the MDetector to start the malware detection process.
* _STOP_: This command will request the MDetector to stop the malware detection process.
* _QUERY_: This command is used by the TAPp to check whether there is any malware detected by the MDetector. It will be performed by the TAPp periodically.  
Figure 4: The design overview of our malware detector.  
Note that: (1) Each command is a collection of \(s\) bits determined during the initialization, which is only known to the TApp and the MDetector, and \(s\) should be large enough to prevent brute-force attacks, e.g., 128 bits. (2) Our design can be easily extended to support extra commands.  
To send a command stealthily to the MDetector, the TApp will leverage steganography. The TApp and the MDetector will share a secret key during the initialization. Each time upon sending a command, the TApp will use a pseudo-random function to select a random portion of bits from a cover message based on the secret key, encode the command into the selected bits (i.e., we simply replace the selected bits with the bits corresponding to a command), and convey the modified cover message (denoted as stepDATA) to the MDetector through a regular write request. The write request will be forwarded to the flash storage medium via the CA. Upon receiving the write request, the MDetector can extract the command from the stepDATA via the secret key. By observing the stepDATA, the adversary will not be able to know there is a secret command embedded because: (1) The adversary cannot compromise the TrustZone secure world and does not have access to both the original cover message and the encoding process. (2) Compared to the size of a regular write request (typically a few KBs), the size of the command is small (only 100+ bits). It is unlikely for the adversary to be aware of such a tiny modification of the original cover message. A concrete example of sending a secret command from the TApp to the MDetector is provided in Figure 5.  
Each time after finishing handling a command, the MDetector should send back a response to the TApp stealthily. Each response is usually a binary value. For example, 1 indicates that the START or STOP command is successfully executed, while 0 indicates a failure; 1 indicates that the malware is detected, while 0 indicates no detection has been detected. To send back such a binary response in a stealthy manner, our strategy is to utilize the delay of read requests performed on the flash storage. Specifically, after the TApp sends the secret command to the MDetector by encoding it into a regular write request on a disk location, the TApp will read the same location immediately. A normal return without extra delay will indicate value 0 while a return with artificial delay will indicate value 1. Note that: (1) For the security concern, the delay value should be a secret and dynamic value. It can be set by the TApp when sending a secret command each time, and this value can also be encoded into the cover message stealthily. (2) The artificial delay should be small enough to avoid being noticed by the adversary. In addition, the artificial delay will be added only after the MDetector has successfully started/stopped the malware detection process or detected the malware. All of them happen rarely and can be reasonably denied as the system delay.  
Figure 5: A concrete example of propagating a secret command 010 via steganography.