# Secure Audio-Visual Data Exchange for Android In-Vehicle Ecosystems
## 2 Setup and Methodology
### Software Implementation  
Since our experiments are exclusively concerned with Android devices, the programming language used for the development was Java and for the cryptographic functions we relied on the SpongyCastle library ([[https://github.com/rtyley/spongycastle](https://github.com/rtyley/spongycastle)]([https://github.com/rtyley/spongycastle](https://github.com/rtyley/spongycastle)), accessed on 10 August 2021). This is basically the BouncyCastle library ([[https://www.bouncycastle.org](https://www.bouncycastle.org)]([https://www.bouncycastle.org](https://www.bouncycastle.org)), accessed on 10 August 2021) with specific changes required to work on Android. For processing the audio signal in the frequency domain, we used the fast Fourier transform implemented using radix 2 Cooley-Tukey [30]. For the QR code generation and scanning operation we used a free library, the ZXing Android Embedded library ([[https://github.com/journeyapps/zxing-android-embedded](https://github.com/journeyapps/zxing-android-embedded)]([https://github.com/journeyapps/zxing-android-embedded](https://github.com/journeyapps/zxing-android-embedded)), accessed on 10 August 2021). As expected, the development of the APK was done using Android Studio and the result consists of two applications, an emitter and a receiver application, developed using a modular architecture. A detailed view of the modular architecture is presented in Figure 4 which shows each major layer that handles the information. Each class has its own responsibilities, e.g., recording, emitting, symbol conversion, elliptic curve computations, etc., and custom parameters, e.g., duration of a single tone, expected number of symbols, frequency range, etc. At the base of the information flow we place the Android classes that handle the recording and emitting of information, i.e., AudioTrack and AudioRecord. Over this layer we add the FFT class and then the SpongyCastle handler which routes the information to the MainActivity class which is basically the user interface. The communication between classes is depicted in the class diagram from Figure 5. The MainActivity class schedules all the work based on the user input. It also constructs all the needed objects (the elliptic curve handler class, the emitter, recorder and the task for extracting noise) for the application startup, passing them the basic information, e.g., sound duration, volume, number of bits in the transmitted symbols, etc. Once the object initialization is over, user input is expected for selecting the curve type and whether the seed from the environment is to be used or not. Also, debugging information can be logged in external files. Once these options are selected, they will be passed to the responsible objects. The ECHandler object will need to obtain only the curve type, while the Emitter and Recorder will need to be informed if the seed is predefined or extracted. The MainActivity class will coordinate the transmission of sounds, using the Emitter class, and the reception, using the Recorder class, then extracts the information, using the ECHandler class. Figure 3: The power spectrum of audio signal recorded (**left**) and played (**right**) by the devices used in our experiments. Figure 4: Implementation stack. Figure 5: Class diagram. Regarding the use-flow, firstly we initiate the seed generation (this is used inside the car for extracting the seed based on the environment noise; otherwise the seed can have a predefined value). After the seed is generated, the key share on the elliptic curve is computed and the operation of emitting, or recording, starts. The seed generation (which is handled by the synchronizationTaskToExtractSeed class), emit and record actions are asynchronous operations, done on different threads. Thus, the main class required an interface through which it could be signaled when the action is over. This is the role of the iOperationReady interface.