# Safe and Policy Oriented Secure Android-Based Industrial Embedded Control System
## 4 Experiment and Evaluation
### Articulacy of the Administrative Policies  
To evaluate the articulacy of the enforced administrative policies, we conducted experiments following the scenarios given by the adversary models in Section 3.3. To demonstrate an adversary attack in the bootloader level, we performed test scenarios such as removing the ALPU and attaching another ALPU with a different encryption key. The behavior of the booting process policies is shown in Figure 6. In Figure 6a, the ALPU bootloader command line command tool was used to check the existence of the ALPU by checking the device address. As shown in the figure, the authentication process was successful, which means that the ALPU is attached to the embedded platform. When the ALPU is removed from the system, Figure 6b results in a failure, which invokes an infinite system reset without the ability to interrupt the bootloader command line in the booting process.  
To demonstrate the second policy, the encryption key of an ALPU chip is stored as a variable in the bootloader environment. As the ALPU chip is configured to run in the hash generator mode, the key encrypted with the SHA-256 encryption algorithm should match the one stored in the respective ALPU. When another ALPU chip with a different encryption key is attached to the embedded system, the authentication process continuously fails, also leading to an infinite system reset. On the other hand, Figure 6d demonstrates a successful boot when the correct ALPU is attached to the JECS-600 ITX. These results show that the bootloader security policies can protect the JECS-600 ITX from any form of attack in the bootloader level.  
To evaluate the articulacy of the policies in the Android application layer, we assume the worst-case scenario: that an adversary has bypassed the booting process security schemes. Accordingly,  
Figure 5: Actual working environment.  
we temporarily disabled the bootloader security schemes to boot into Android and imitate an adversary attack. Due to the fact that applications without the encryption library or the encryption key abruptly terminate, we focus on demonstrating the authentication of the ALPU key value in the Android application layer. We created a simple Android application, implementing the encryption library to verify the key value stored in the ALPU. The application encrypts the key with SHA-256 algorithm and sends it to the ALPU for verification through the I\({}^{2}\)C port. Figure 7a shows that the ALPU authentication is successful when the correct ALPU is connected to the embedded platform. However, the process fails with a different ALPU, as shown in Figure 7b.  
Figure 6: Demonstration of the booting process policies: **(a)** With ALPU; **(b)** Without ALPU; **(c)** ALPU with different key value; **(d)** ALPU with the same key value.  
Figure 7: Demonstration of the Android application layer policies: **(a)** ALPU with the same key value; **(b)** ALPU with different key value.  
With these results, the embedded platform is protected not only at the bootloader level, but even in the Android application level. As the authentication process with ALPU chip is only performed once, when the application is executed, there is less overhead compared to the existing software security techniques in [17; 18; 19; 20; 21; 22]. Implementation is also relatively easier when developing a new application because only one line of authentication function is added to the original application.