Online and mobile banking has revolutionized the way we manage our money. We can send money, transfer between accounts, and even deposit cheques from the phone in our pocket. The challenge with introducing convenient banking features is ensuring the customer’s information and finances remain secure throughout the whole process without introducing unnecessary complexity. To accomplish such a large feat, banks use state-of-the-art security technology such as biometric authentication on mobile applications and advanced web protocols. However, there is one feature of online and mobile banking which we believe has the potential to compromise the user’s private data. This is that the only way to download bank statements from the bank website is as a PDF document which is not secure. The bank statement contains a lot of private user information, such as transaction history, account numbers and balance, and personal information such as address. All this information is being stored in plain text on the local storage of the user’s device once it is downloaded, creating a possibility for data theft if the customer’s computer is compromised.
Our proposed solution is the Bank Statement Encryption (BSE) Protocol. BSE is our method of securing a user's bank statements while still being able to keep them locally on their machine at all times, without needing internet access. This is perfect as it will allow the user to still feel like they have ownership over their bank statements while at the same time reducing the risk of their private information and account details being compromised. How it works is that instead of downloading an unencrypted PDF, the user will be able to download an encrypted PDF through their mobile app. When they do this, the password for this encrypted PDF is also sent to them but is stored within the secure Keystore or Keychain, depending on the platform. The user never actually has to or is even able to look at the password, this will stop them from just writing it down somewhere encrypted on the phone and compromising the security. To view the PDF bank statement, the user simply needs to go back into their mobile app and provide bio-authentication, this then allows the app to read the password from the secure storage which then allows the app to open the PDF and show it to the user. Doing it this way, the plaintext bank statement is never actually stored on the phone but the user is still able to save them on their phone and access them without internet access.
The implementation can be broken down into serval parts: sending the user the encrypted statement, storing the information used to decrypt the statement (whether that be a password or a key), storing that information safely on the device, and allowing the user to access it after via biometric authentication. The biggest design choice was deciding between using the standard included password-based encryption that PDF’s support, or using your own in-house method of encrypting the files. For our implementation, we used the default encryption that the PDF file format supports because it was simpler for us to put together in the short time we had. However, the actual difference in implementation between the two methods is very minor, just changing what you store in the Keystore or Keychain on the user's device. We created a mock banking app that allowed a user to download their bank statements and keep them saved on their phone. When the user requests to download a statement, two things are securely sent to them, an encrypted PDF containing their statement, and the password to decrypt that PDF. In our implementation, we thought actually sending something from a server would be unnecessary so we streamlined the process by just storing the encrypted PDFs and their passwords in the project. Obviously, if a real bank were to do this, they would have to actually send the user this information. The password is then saved into their phone's Keystore or Keychain so that it can be secured. Importantly, the user can’t interact with this password at all, stopping them from compromising the security by storing it in plaintext somewhere on their device. After the user downloads their statement, they are then able to return to the app at any time to view any of their previously downloaded statements. To view them, they have to provide bio-authentication which then allows the password to be read from the secure container on their phone. During this process, the unencrypted PDF is never saved onto the phone, only ever loaded into memory. If an actual bank were to implement this idea, an important feature that the bank's mobile app would have to incorporate would be changing its offline behavior in the following way. Instead of being prompted to log in, which they couldn’t do anyway because of their lack of internet connection, they will be brought right to the screen which will allow them to view their previously downloaded statements, after the proper authentication of course.
The demo of our app was made using flutter, and android studio. Flutter is an open-source UI SDK that allows users to develop applications for a variety of platforms, specifically for this project, Android. With Flutter, we were able to utilize a variety of open source packages created for flutter that aided in the construction of the application demo. These packages include: google_fonts: Used to gain access to a variety of fonts for the application flutter_svg: Used to handle SVG files we used for our logos local_auth: Used to access biometric authentication on android device fliutter_secure_storage: Used to store the pdf passwords in Keystore Flutter_pdf_viewer: Used to handle viewing pdfs
Challenges we ran into
The challenges that we ran into while designing this demo were plentiful, but three major challenges truly challenged us and forced us to deepen our understanding of the concepts we were attempting to tackle. First of all, learning flutter and dart was an extremely long task. We had to learn how flutter and dart worked in order to create our demo. The fundamental way that the SDK worked was different from what we were used to as developers. We had to overcome this by engaging in long and detailed tutorials that taught us basics and built our knowledge up before we even wrote a single line of code. The second challenge we faced was finding pdf packages that worked. Because flutter uses open source packages in order to expand its libraries, there were many options for a package that handled pdf however as we soon realized, very few met our specific needs. On top of this, the documentation for many of these packages often lackluster, requiring us to look at the actual libraries and trying to understand what features they possessed. This coupled with the sheer number of packages we tried helped us become more comfortable with using flutter and dart. Finally, we were compelled to learn how encryption works and how it is implemented in existing protocols in order to create this project. This was especially true for the PDF file format, who's official implementation of encryption we had to learn how to use and integrate into our program.
What we learned
To create a working demo, we had to familiarize ourselves with the intricacies of mobile app development. This involved learning how to design a pleasing and convenient UI for users as well as having our important functions run behind the scenes to prepare our data. This app aided us in expanding our knowledge and capabilities in both front-end and back-end development. Learning to create this mobile app also forced us to learn flutter, as well as the language dart. No one in our group knew how to use these tools when we first started. As such, we had to learn from the ground, first how to program in dart, and use flutter with dart to actually create our app. We had to learn about the different packages, classes, and overall project structure that culminated in an understanding of the SDK and language. Finally, we learned the basics of file encryption. We explored many avenues when designing a means for our demo to decrypt, read and encrypt pdf files. We learned about the AES and the means by which it encrypts files and stores keys. It helped us reformulate our understanding of what security is.
What's next for Bank Statement Encryption (BSE) Protocol
This protocol was designed to protect against identity theft by patching a hole in the existing bank security network and so, ideally, we would like to work with banks to implement our idea and service into their existing apps. This would increase the security of their users' information and provide them more privacy all while continuing to allow them to take control of their data. However, regardless of whether or not we were able to partner with a real bank, the next major update for BSE is to incorporate a web app that utilizes this protocol since not all banking is done on smartphones. Increasing the accessibility of BSE would be integral to its growth and its adoption by banks and users alike. Alternatively, if no bank wants to incorporate our idea, we could run the app as a service that anyone would be able to download on their phone to protect their bank statements or even other sensitive information. All of these provide a concrete example of the useful nature of this protocol.