Home
In this section, we overview the project's model & system architecture and introduce our solutions to several security concerns.
The charts above demonstrate the story map of the mobile app. From the user's perspective, the app design can be divided into four stages. For each stage, we list our goals for a skeletal product and a minimum viable product (MVP), as well as other stretch goals. Brief implementation tips are also included.
The system contains an Android frontend application and a Python backend server, communicating via HTTPS.
To generate a new digital watermark, a user must register and log into an Author account. The app will then request a unique tag from the backend authentication handler and invoke the local steganography SDK to embed the tag in the image provided by the user. Meanwhile, the user may add custom messages to the watermark and encrypt them with a passcode via the local crypto SDK. Before exporting the "stamped" image, the app will upload all the messages along with the image checksum produced by the crypto SDK, which will be paired with the tag in the NoSQL database through the main handler.
Whoever receives the image, known as the Viewer, can retrieve the digital watermark without login. The app will extract the tag, query the main handler, and verify the image checksum. Aside from public messages, the viewer may also enter the passcode to access the encrypted messages.
To further illustrate how each module works, we list the Q&A to some common cybersecurity concerns. Note that some measures are not guaranteed in the minimal viable product.
- Can attackers invalidate my watermark by modifying some pixels / taking a screenshot / adding noise / reformating / compressing / cropping the image?
It depends on the steganography algorithm. For the minimum viable product, we intend to use the Least Significant Bit (LSB) method. By embedding redundant information, the watermark can resist cropping attacks. For the stretch goal, we intend to use a more robust model based on machine learning to resist most modifications. For example, StegaStamp can retrieve the embedded information from an image that is printed out and rescanned. To destroy the watermark, the attacker has to modify the image thoroughly, creating identifiable artifacts. More discussion about the steganography algorithms can be found here.
- Can attackers forge my watermark or photoshop the image without being noticed?
No, as long as the attacker does not know your account password. The checksum guarantees that the image cannot be modified without being noticed.
- Will my private data be uploaded to the server?
We attach great importance to your privacy and hence our backend only asks for minimal information. Your account password will be salted and hashed before being transmitted to the server. Your IP address is not recorded. The base image for digital watermarking also stays locally - only a secure hash is uploaded. The message part is a bit tricky. Since the image can only store limited information, we have to store your watermark message on the Cloud. We intend to solve this privacy issue by encrypting all the information with a random key, which is generated locally and embedded in the image together with the tag. As the image is not uploaded, the server cannot decrypt the message.
- Can I choose not to expose my username in the watermark?
Yes, you may choose to keep your username and the timestamp information private when generating the watermark. You can later publish them when there is a copyright conflict.
- Can attackers guess the tag of mine without access to the picture?
Theoretically yes, but practically NO. Each tag is a 56-bit long random number. Even if the app has a million users, only 1/70000000000 of the tags are valid.
- Can attackers determine the timestamp of my watermark by comparing tags?
No, because tags are not generated in increasing/decreasing order.
Alphabetized by last name. Each team member has made significant contribution to this project.