-
Notifications
You must be signed in to change notification settings - Fork 0
Design Doc
This project was developed to allow people to encrypt their photos immediately upon taking them. This is not easily done with currently available cameras, yet it is important for those who take photos in precarious situations. Our canonical example of a group who would need this technology are journalists who take pictures in countries under oppressive regimes and so could have their cameras searched for controversial material.
We want photos to be confidential and hidden, but accessible to the photographer for later use. Our functionality goals include taking encrypted photographs and then decrypting them. Our encryption needs to be cryptographically secure so that the photographs could not be seen by an adversary. Another goal is that the plaintext photographs not be recoverable from memory without some private key. The encrypted photographs also need to be hidden so that the camera would not appear suspicious. Lastly, the camera needs to be able to take unencrypted photographs, both because these could provide some cover for the photographs that were hidden and because people generally expect to be able to take and review unencrypted photographs with their camera.
Our non-goals include anything that would be infeasible to implement or would distract from our goals. This included decrypting photos on the camera and allowing for remote photograph access and/or backup. In terms of security, we do not protect the integrity of the keys and integrity of the photos. We also do not protect against compromised hardware/software, destruction/corruption of data, or immediate confiscation as they are outside the scope of this project.
The system design is split into three parts. First, there is a computer application that generates the asymmetric keys. These keys are then transferred over to the second part, which is a camera application that takes photos, generates symmetric keys, and then encrypts those photographs with the symmetric keys and encrypts the symmetric keys with the asymmetric public key. These encrypted photos and keys are then stored until being transferred back onto the computer. Then they reach the third part, which is a program on the computer that then decrypts and stores the plaintext photos.
To implement our design, we forked Open Camera, an open-source Android camera application. We added a cryptography package and modified files to leverage the new encryption capabilities. We also implemented multiple desktop Java programs to generate keys and decrypt photos. Last, we modified the application’s settings menu to allow users to enable and configure the encryption functionality. For the implementation of our encryption, we used Salsa20 for symmetric encryption and RSA for the asymmetric.
Our implementation meets our primary security goals. We use standard ciphers and libraries to gain cryptographic confidentiality. We hide the encrypted photos by having a separate save location and by hiding the encryption settings. And the photographs and the symmetric keys are not recoverable from memory without the asymmetric key unless the phone is compromised quickly after using the application. Thus, the final program is able to meet what we set out to do.
This project began as an expansion of the Magic Lantern add-on for Canon DSLR cameras. Magic Lantern lets Canon cameras run code from SD cards, allowing for a wide set of additional functionality to otherwise standard cameras. We intended to use it to allow users to immediately encrypt photographs they take. The target audience was photojournalists who take pictures in dangerous situations. Yet due to constraints in the implementation of Magic Lantern and our own lack of embedded programming experience, we were forced to abandon Magic Lantern after a few weeks of work.
After that, we chose to implement our system on Android smartphones. Although it is not ideal, our implementation acts as a proof of concept for the system. Also, as smartphone cameras get better over time and are used for more serious photography, it could become a viable option for those concerned about the security of their photos.
Our system offers an improvement over the default encryption features of Android by making it impossible for anyone to decrypt the encrypted photos without using a private key stored on a separate (and hopefully more secure) computer. A limitation of is that the photographers themselves cannot decrypt and view the photographs until they are on their computers, but for the project, this was viewed as less important than the security of the photographs. Additionally, since cameras can be confiscated and reviewed by authorities, our application endeavors to hide the presence of encrypted photos on the smartphone. All of these help to maintain the security and privacy of photographers with sensitive photos.
As it is implemented, our system consists of a Android smartphone, a modified version of the Open Camera application, a key generation program on the user’s computer, and a decryption program on the user’s computer. When pictures are taken they will be encrypted and stored in the phone’s internal storage or on SD card from which they can later be decrypted on the user’s computer. As long as the computer is secure, it is the only device able to decrypt all of the photos, as only it will have the necessary cryptographic secrets.
The only valid user of the system is the photographer, who is assumed to have control of the phone and the computer.
Functionality Goal 1. Take Encrypted Pictures. If the application is set to encrypt, the pictures are encrypted immediately after being taken.
Functionality Goal 2. Take Unencrypted pictures. The module can be turned off and non-encrypted photos taken, stored, and reviewed.
Functionality Goal 3. Decrypt encrypted pictures on trusted computer. Encrypted photos can later be decrypted by a computer which has access to some secret.
Functionality Goal 4. No clear presence of encrypted photos. Encrypted photos are hard to find, without the need for the photographer to take a bunch of extra pictures.
Stretch goals:
Stretch Goal 1. Delayed encryption. Inaccessibility of photos can be delayed using a timer, sliding window, or dead man’s switch.
This project will encrypt certain photos as they are being stored. It will encrypt files if and only if the encryption module is turned on, allowing the photographer to take photographs that are not encrypted and so can be reviewed. It will also correctly decrypt and display the photos when the are transferred to the user’s trusted computer. When looking at the phone, the photos will be hard to find.
Functionality Non-goal 1. Decryption of photos on camera. The phone will not be able to decrypt or display photos that have been encrypted, with the exception of temporary review functionality for making camera adjustments.
Functionality Non-goal 2. Remote photo access/backup. If the SD card/phone is stolen or confiscated, the photographer will not have a way to access the photos.
Functionality Non-goal 3. Fully recoverable / RAW pictures. The pictures stored are not guaranteed to retain all of their original bits. Compression or conversion may be used as part of the process.
- Photographer: Trusted, should have the ability to take and view pictures. Should not be able to be coerced into revealing decryption secrets
- Makers of the hardware (phone, computer, SD card, etc.): Trusted out of necessity
- Open Camera contributors: Trusted out of necessity
- Developers: Any programmer who writes code that is written to the computer and the phone. This includes:OS developers, Us, Developers of (potentially malicious) applications installed on the computer or phone
- Anyone who confiscates the hardware, including law enforcement (adversary), in US could not force divulgence of encryption key; foreign regimes (adversary), could coerce photographer into divulging cryptographic secrets; corporate security (adversary), in US could not force divulgence of encryption key
- Rival photographers / news organizations
- Whoever can access the computer: Anyone with access to the computer and phone could decrypt the photos, photographer must trust that the computer is secure
- Photos, accessed by: use of the photo viewer, connecting the phone to a computer, inserting the SD card into a computer, analyzing all memory on SD card using special equipment. Destroyed by confiscation or destruction of SD card or phone
- Liberty of photographer, at risk if sensitive photos can be found on phone or SD card
- Security of the phone
- Public/Private key pair being used
- Symmetric keys
Security Goal 1. Photo encryption should be cryptographically secure. Without some secret, photos cannot be decrypted in any reasonable amount of time.
Security Goal 2. Photos to be encrypted should only be saved in a secure format. To avoid problems with memory non-deletion on flash storage, pictures should never be written in an unencrypted format.
Security Goal 3. Relevant keys are securely stored. In order for the encryption to secure, the privacy of the relevant symmetric and asymmetric keys will be maintained in storage.
Security Goal 4. Relevant information is hidden in addition to securely stored. For the presence of the information to not be immediately available on first glance, the information will be hidden.
Stretch goals:
Stretch Goal 1. Presence of encrypted photos should be deniable. Photos could be hidden using steganography.
Security Non-goal 1. Protect against compromised hardware/software. Does not endeavor to protect against eavesdroppers in the phone or viewing the computer. If the phone, computer, or SD card is compromised before or while running our software, we can’t protect against adversaries viewing the photos or getting the encryption keys.
Security Non-goal 2. Protect against destruction or corruption of data. Does not protect against the loss of the photos that are destroyed or permanently confiscated.
Security Non-goal 3. Protect against immediate confiscation. If the phone is confiscated during or shortly after the act of taking sensitive photos, we can’t guarantee that the photos will be inaccessible.
Security Non-goal 4. Protect against physical assault. Physical attacks on any of the assets are outside of the scope of this project.
Security Non-goal 5. Protect integrity of the keys. Outside the scope of this project are protecting the integrity of the public key or private keys in case of an adversary compromising either of them.
Security Non-goal 6. Protect against wifi related hacks. Outside the scope of this project is any sort of network attack - the photographer will either have to temporarily disconnect from the network or use at their own risk.
Part of our project will be a desktop application that generates asymmetric keys. When the user connects their phone and activates the application, the computer will generate a RSA key pair. Then, it will store the private key locally on the computer’s hard drive and store the public key in the phone’s memory or on an SD card.
Part of our project will be a desktop application combined with the key-generating application that can decrypt the photos from the phone and move them to the desktop. The computer will first extract the encrypted photos from the phone. Then, it will decrypt the symmetric keys which will then be used to used to decrypt the photos.
The encryption module will be activated from a menu within Open Camera
If the encryption module is enabled, then a symmetric key will be generated every time a photo is taken. The photos will be encrypted immediately after being received from the camera using this symmetric key, without every being stored in plaintext. The symmetric key will then be encrypted as well, using the asymmetric key, and connected to the photo.
If the encryption module is not enabled, the photos will be stored normally.
The encrypted photos and keys will then be hidden.
Meeting Functionality Goal 1. Take Encrypted Pictures. The encryption stream is inserted into the save functionality if the application has encryption turned on.
Meeting Functionality Goal 2. Take Unencrypted pictures. The ability to take unencrypted is met by allowing the user the option to turn off the encryption.
Meeting Functionality Goal 3. Decrypt encrypted pictures on trusted computer. This is done through the computer program, which given the encrypted keys, the ciphertext photo, and the private key can decrypt it to reveal the plaintext, as is specified by Section 4.1.2.
Meeting Functionality Goal 4. No clear presence of encrypted photos. To hide photos, photos can optionally be stored in an obscure directory and have a non-image file prefix so that the android gallery application will not open them.
Meeting Security Goal 1. Photo encryption should be cryptographically secure. Photos are encrypted with a symmetric stream cipher with a random key and initialization vector. The key and initialization vector are then asymmetrically encrypted with the user’s public key and prepended to the encrypted image file.
Meeting Security Goal 2. Photos to be encrypted should only be saved in a secure format. The photos that are to be encrypted are encrypted before being written to the file system and then the in memory representation of the photo is destroyed.
Meeting Security Goal 3. Relevant keys are securely stored. As explained in the symmetric keys used to encrypt the photo will be encrypted and then stored in that encrypted format and never directly saved.
Meeting Security Goal 4. Relevant information is hidden in addition to securely stored. Currently photos can be stored in any directory and use a non-image file suffix.
SD cards and smartphones use flash memory, which has a finite number of write cycles before it permanently degrades. Therefore, SD cards delete files by simply marking regions as “available” without overwriting them, and then make an effort to distribute future writes to other regions of the card. As a result, any photos (or keys) written to the memory cards as plaintext would take a long time to be fully erased and could possibly be recovered by manually viewing the card contents.
If the computer is compromised then the adversary could view the files as they are being decrypted or have access to the primary key and so be able to decrypt them on their own. The same is true for the phone, where if an eavesdropper is installed, it would be able to have camera access.
There is no protection against users being tricked (or coerced) into giving up access to the private key if the user knows it. There is also no protection against a lost in security or functionality due to a physical attack. Should the phone be taken or destroyed, which is outside of the scope of this project, the photographer will not be able to protect their photos against removal or corruption of data.
There is no protection against someone changing the keys in the phone in some way. This attack could be done by changing the public key as it is stored on the phone, which would prevent the photographer from decrypting the symmetric keys and so their photos. But this is outside the scope of this project.
This project does not protect against lost or corrupted data. For example, the project cannot protect against the above mentioned physical attacks or wifi-related attacks, which could result in the loss or corruption of stored photos and keys.
The frames that are shown to the user while they are using an application that uses an Android camera are stored in a temporary buffer that can be recovered (1). So, if an adversary were to get ahold of the phone right after the photographs had been taken, then they could recover whatever the viewer had seen when taking the picture.
The project can be found at https://github.com/carmenyh/open-camera-crypt.git. To run the project, one will need an Android phone that can run Open Camera or the ability to emulate one on a computer.
First, pull the project from gitlab and import it into Android Studio as a Gradle project.
To use:
From the Build menu select generate APK and click the bubble which will pop up to go to the location of the APK in your computer’s file system.
Transfer the APK to your phone and install it. You will have to enable developer mode and allow installation of non-Play Store applications to do this.
Run the key generation program (KeyGen) on your computer with two optional location/filename arguments: that of the public key for the computer and that of the private key. A final optional argument is a passcode with which to encrypt the private key.
Transfer the public key generated to your phone.
In the Open Camera settings, select “More camera controls…” and scroll to the “Encryption” heading.
Turn on “Encrypt photos” and select the public key file on the phone.
If desired, set the “Encrypted save location” to change the output directory for encrypted photos. Take some pictures.
Transfer the “.encrypted” files from the encrypted save directory to your computer.
Run the decryption program (Decryptor) with three arguments: the filepath of the private key, the folder with the encrypted files, and the folder to send the decrypted files to. In addition, if a passcode was used to encrypt the private key, that will also need to be passed as an argument.
The bulk of the project is the source code for the Open Camera application. We have modified:
- preferences.xml
- strings.xml
- FolderChooserDialog.java
- ImageSaver.java
- MainActivity.java
- MyApplicationInterface.java
- MyPreferenceFragment.java
- PreferenceKeys.java
- StorageUtils.java
- UI/FileChooserDialog.java
- UI/FolderChooserDialog.java
- Crypto/*
We also modified some build files and such but those probably will have no impact on the security or lack thereof for the project.
We added multiple options in Open Camera’s settings to:
- Enable or disable decryption
- Select the location of the public key
- Select the directory in which encrypted photos should be saved
These settings are integrated with Open Camera’s existing user preference system which uses standard Android APIs to achieve persistent settings. Open Camera already had a small folder picker which can be used to select the save location for photos. This browser was reused to allow users to select the encrypted save location and was modified to make a file picker for the public key.
Once the user has selected a new public key file the path of the file is saved as a user preference. Each time the user takes a picture the camera checks whether or not it has a public key and if it does not it reads the public key file and saves the public key. The application reads the public key file with some functions from the Java standard security library. If the public key file cannot be found then the application reports its failure to save the photo.
Photos are saved in an encrypted format by wrapping the file output stream that the application uses to write out the photo in a ImageEncryptionStream of our own design. The stream is initialized with a public key. First it generates a symmetric key and initialization vector for a Salsa20 stream cipher from the Spongy Castle library. Then the symmetric key is encrypted using Java’s security library implementation of an RSA block cipher. The length of the encrypted symmetric key is written, then the length of the initialization vector, then the encrypted symmetric key and finally the initialization vector. The symmetric key and initialization vector are used to initialize the Salsa20 cipher and then deleted. At that point the encryption stream is initialized. From then on, the output stream is wrapped in the Salsa20 cipher so all the image data that Open Camera writes gets saved in an encrypted format.
To save photos we use modified versions of Open Camera’s saveSingleImageNow and saveImageNowRaw functions. Our versions; saveSingleEncryptedImageNow, and saveEncryptedImageNowRaw use a different (though by default the same) save location which corresponds to the location the user selected in the settings. Our functions wrap the output stream as described above and also strip out functions which would leak the image data such as those that broadcast the presence of a new image to other applications.
A 2048 bit RSA public private key pair are generated on the secure computer and then written to two files; one for the public key and one for the private key. The public key file is copied to the phone so that it can be used to encrypt the symmetric keys used to encrypt images.
Photos are encrypted in the following format:
Byte 0: The length (in bytes) of the ciphertext which resulted from encrypting the symmetric key used for the Salsa20 cipher
Byte 1: The length (in bytes) of the initialization vector for the Salsa20 cipher
Bytes 3 - X: The ciphertext of the symmetric key
Bytes X+1 - Y: The initialization vector
Bytes Y+1 - end: The ciphertext of the photo
Decrypted bytes 1-4: The length of the original file’s file name
Decrypted bytes 5-X: The original filename
Decrypted bytes X +1 - end: The image data
To decrypt the photo we first read the lengths of the encrypted symmetric key and initialization vector. Then we read and decrypt the symmetric key and then read the initialization vector. The symmetric key is decrypted with the generated private key. Then we read the length of the original file, followed by the original filename. We then create a file with that name. Last, the photo is decrypted with a Salsa20 cipher using the symmetric key and initialization vector and written to the created file.
Encrypted images are not written to a file in an unencrypted format by Open Camera
We looked at all the usages of file I/O that we could find in Open Camera to trace where data from the image goes and ensured that the only file operation in saving the image data when it should be encrypted occurs through our encryption stream.
If the image should be encrypted, other applications are not notified
We looked for places where the Open Camera broadcasts to other applications to ensure that it does not leak data as to when photos are taken, though the time of the photo is still currently being saved with the photo.
Assuming Java’s standard library RSA functions and Spongy Castle are not broken, images are written in a cryptographically secure format.
We all checked our use of cryptographic functions to make sure that everything that needed to be encrypted was, and with the right algorithms.
The time the photo was taken is stored with the photo and that could be incriminating if the encrypted files were found.
The recycle method is called on the bitmap containing image data after it is saved to a file. This is a performance consideration from Open Camera, however if data in the bitmap was not overwritten quickly it could be leaked.
We were storing the private RSA key for image decryption in a plain text file on the user’s “secure” computer this means that an adversary with control of the “secure” computer would be able to decrypt the user’s photos.
The Bitmap object which in some cases hold image data has a very large memory footprint and so is managed by the operating system for performance reasons. As such it is difficult to say what happens to the buffer after it is “recycled.”
Currently images are stored with the .encrypted extension which makes them quite suspicious if found, however it has the benefit of stopping them from appearing in the phone’s gallery application.
The encryption settings in the application are not hidden which means that a technically inept but suspicious individual could find them. What this would mean could vary greatly depending on the context.
We are using RSA without padding to encrypt the symmetric keys, which is insecure. This insecure for multiple reasons, one of which being that it leads to determinism, which means the attacker could know if the same symmetric key is used twice.
There is no authentication done on the plaintext. This means that an adversary could change ciphertext, and thus the plaintext, without the user knowing.
There is little we can do about the fact that the Android operating system and any applications which have compromised it or have sufficient permissions can see the image data we are handling and could therefore leak it in an unencrypted format. We endeavor to minimize the leakage of image data and metadata to other applications, however some potential for leakage is unavoidable.
Beyond things that might compromise our application, many applications on Android obtain permission to use the camera and so other applications could conceivably be made to record anything the user might take a photo of.
Given that we are not attempting modify the Android file system, it would be difficult to completely hide encrypted files.
The crypto libraries used - including Spongycastle, java.security, and javax.crypto - are assumed to use secure implementations of the ciphers and have a good source of randomness.
Since one foundational assumption of this project is that the user has some trusted computer on which to perform the encryption and decryption of photos this section will primarily focus on attacks that do not occur on the computer.
Since we make no checks to determine whether or not keys are being written to internal or external media, a user could inadvertently write their private key onto a phone or SD card which would break the security properties of the entire system. Even if the user wrote the key to the phone or SD card and then deleted it, there would still be a vulnerability as a result of the wear leveling problem described in previous sections. This, though, is outside the scope of our project.
Photos are stored with a .jpg.encrypted or .dng.encrypted file extension which makes it very obvious what the files are. This will be changed to have random file names, but will still be stored with a .encrypted ending. The encrypted picture files include a timestamp in the name which could be suspicious if the user was known to be in a photo-prohibited area at that time. This will be changed.
Methodology This analysis was done in majority through reading and analyzing code, but also makes use of Fortify SCA results.
Sufficiently secure
Once the encrypted data is written to disk, the image data is handled appropriately. The plaintext image is never stored in a file and is not used further by the program.
Metadata is (within our control) not written to the file when in encrypted mode, so there is no way to directly obtain metadata from the camera application or file itself.
Might have issues
Java memory management is largely opaque to the user. As such, we have not taken any precautions about sensitive regions of memory. These regions could remain in memory for a long time before garbage collection or even be written to disk as a result of paging. Potentially sensitive information that would appear in memory includes generated symmetric keys, plaintext image data as it is processed, and metadata such as photo location. This will be investigated before the final implementation.
The encryption used 1024-bit RSA, which is considered insecure against particularly powerful computers. With a cracked RSA key, an attacker could access the plaintext images. The RSA key size will be changed to 2048 bits.
Phone-wide metadata is not handled carefully enough. Currently, any knowledge about the time of the image could be cross-referenced with location data (Google constantly tracks a phone’s location, and cell carriers probably do too) to determine where pictures were taken.This should be somewhat addressed by the final implementation.
Methodology
Evaluation of the preferences/image storage/interaction with other applications took place mostly through looking at the process in the source code.
Sufficiently secure
The specific preferences do not appear to be accessible by other applications, which would cause a vulnerability in where the private key is loaded from. Although the preference keys are in a public class, the context does not appear to be set to allow the preferences to be readable by other applications.
The image saver appears to save images as encrypted in all cases where an image would be saved.
Might have issues
The encryption of the images is not authenticated encryption, which means that an attacker could forge a message/ciphertext. But this is fairly irrelevant, as the focus of the project is on privacy, because of an assumed single user. So it will not be addressed.
There is an option to save the save location history, which could cause problems in revealing data about the existence of the images, and encrypting the photos does not appear to automatically change that. This will be further investigated for the final implementation.
The images once existed in memory, and it’s possible that when the data is freed there is no secure erasure, so by analyzing it someone could recover the plaintext. This will be investigated, but it is unclear whether anything could be done to fix it.
Fortify listed the following 3 issues:
-
[Critical] Key Management: Hardcoded Encryption Key This was a false positive. The “key” in this context was meant in the “key-value” sense, and the issue was in parts of the code that we didn’t write. It is slightly interesting that it didn’t pick out the other myriad of similar hardcoded keys. There are no security concerns regarding this issue.
-
[High] Weak Encryption: Insufficient Key Size This occurred in the KeyGen class, and was the result of using 1024-bit RSA encryption. 1024-bits is indeed considered insecure, so we will raise the key size to the minimum 2048 bits. We don’t think this will have a significant impact on the performance of the key generator.
-
[High] Weak Encryption: Insufficient Key Size This occurred in the BogusPublicFileKeyGenerator class, and was the result of using 512-bit RSA encryption. Since 512 is indeed insufficiently secure, this warning is valid. However, the file is clearly not meant for a “production” environment. In fact, the file was only a shim to allow us to test the encryption before worrying about transferring key files from the computer. As such, we plan to patch this issue by removing the file.
In the non-goals, the computer was assumed to be secure, as to compromise the security of the computer would reveal information about the decrypted photos that are stored there and so break confidentiality. Yet, given that the encryption of private asymmetric keys if fairly standard practice, we chose to add that functionality to our own key generation. This was done through encrypting the PEM-formatted key file using Salsa20 with the key as a hash of a user inputted passcode. Then, the process was reversed upon decryption.
Previously, when encryption was enabled but the chosen folder didn’t contain “pub.pem”, the application would crash. To fix this, we implemented a file picker (rather than using the existing folder picker) and triggered the file picker whenever the user enabled encryption. If the file picker was canceled, it would disable encryption. We left the button that allowed the user to choose a new public key file if desired.
While there is a risk of an adversary examining the phone, finding the encryption settings and becoming suspicious, we did not think it made sense to obfuscate the encryption settings any more than we already have. Further obfuscation would make the application more user hostile and cannot provide any solid guarantees against being found
Originally, a 1024-bit key was chosen to hopefully better the speed of asymmetric encryption on a camera. However, when the project was changed to use Open Camera, speed of asymmetric encryption became less of a problem. And as a 1024-bit RSA key is considered insecure, it made sense to change the key size to be 2048 bits. So we did so, and when this caused implementation errors, changed the implementation to allow for an encrypted symmetric key size of 256 bits.
We changed the naming scheme for our encrypted images to use a random hex string followed by “.encrypted”. This means that we no longer leak the timestamp of the image in it’s name. We also encrypt the original name of the image in the body of the encrypted file and restore it when decrypting.
To further protect against the leakage of image metadata we attempt to change the last modified timestamp of the encrypted image files to the unix epoch.
We also traced through the image pipeline and attempted to remove all code which leaks image metadata such as location to the operating system.
While the use of a non-image file extension on the encrypted images prevents them from showing up in a gallery application, their presence in the save location for other photos could give away that they are and it makes them easier to find. To prevent this, we added a setting which allows users to change the location to which their photos are saved. The save location defaults to the save location for unencrypted photos.
Within team analysis
- Traced data through the code
- Researched details of Android and how memory and data objects are treated
- Swapped work areas so everyone was looking at fresh code
- Tested UI by trying different combinations of buttons and such to make sure crashes had been fixed
Peer analysis
- Source code analysis
- Internet research on the security of RSA keys
- Exploring the Android file system through both a file browser and the use of a USB cable
- Setting up the application
- Using the application and analyzing the saved files
Separate encrypted vs normal save location
Problem: Encrypted photos are saved to the same save directory used for normal photos, making them easier to find
Solution: Solved by adding a setting for the encrypted save location
Public key not set bug
Problem:The application crashes on taking photo if the user has enabled encryption without specifying a valid key file.
Solution: Implemented a file picker to select the key file. File picker is triggered when the user enables encryption. If the file picker is canceled, encryption is disabled.
Hiding Encryption Setting
Problem: The encryption settings are not well hidden.
Solution: Decided that current level of hiding is sufficient for protecting against casual observation and provides reasonable usability.
Passphrase encrypted private key
Problem:The private RSA key is stored unencrypted.
Solution: Added encryption to the RSA key file.
1024-bit RSA Key Security
Problem:1024-bit RSA keys are considered deprecated under some standards.
Solution: Upgraded to use 2048 bit keys.
Image metadata leakage
Problem:Encrypted image files leak the original filename, extension, and timestamp.
Solution: Replaced file names of encrypted files with random hex strings and encrypted original file name within file to be restored upon decryption. Also change the last modified time of files after saving image.
Hiding Encryption Setting
Could hide encryption settings better with more time but would require UI design knowledge to get it right
All other issues were addressed
The security evaluation raised some useful points, such as the problem with image metadata leaks, which allowed us to make our application more secure in meaningful ways. Some of the other suggestions such as hiding the encryption settings better were very subjective and difficult for us to address. Overall the security evaluations gave us a great appreciation for the difficulty of security auditing. When analyzing the other team’s code, it would have been helpful to have more time to analyze it and to have had it better documented and complete. Ultimately our biggest barrier was not understanding every aspect of the other team’s code and being unable to test it. Once we got feedback we had sufficient time to address the issues it raised.
Saltaformaggio, Brendan, Rohit Bhatia, Zhongshu Gu, Xiangyu Zhang, and Dongyan Xu. "VCR: App-agnostic Recovery of Photographic Evidence from Android Device Memory Images." Proceedings of the ACM Conference on Computer and Communications Security 2015 (2015): 146-57.