ITS450 is a course about software assurance. It is not a programming course and it is not a software engineering course. In fact, while all of the students had taken some programming classes, their general programming proficiency was low.
The goal of these projects was not to produce the next killer app. The goals actually were not primarily about programming. Instead, the goals included having the students create a fairly complex program that they could then take through the phases of software assurance. The scheduling meant that the groups were required to complete the first phase of programming -with a working, executable program before the class had learned about the more serious vulnerabilities like buffer overflows. This was intentional.
The first phase of the projects was the programming. The groups were given intentionally vague requirements and sent off to create the applications. They could ask for more information, although there were very few questions.
The second phase was black box testing. Each project was checked to make sure it actually worked and then the executable file was given to a different group for the black box testing. Because students are not part of a software engineering course, they were provided a document to explain black box testing and give them a template for documenting their results.
The third phase was white box testing. This time the original source code was given to the third group – so that each group saw every other group’s project. Again, students were given a document explaining white box testing.
The fourth and final phase of the project was vulnerability corrections. The groups were given the results of the black box testing and the white box testing and had to make corrections for the documented vulnerabilities. The groups then documented these changes in formal release notes.
The students worked hard and did great work. They faced the programming challenges as well as the issues of vague requirements, documented vulnerabilities and bugs that could not be duplicated and the demands of the documentation.
What follows are the synopses for each group project, links to the projects on SourceForge and a link to the video of their class presentation.
Video Presentation
TwitrCrypt
TwitrCrypt was developed by a group of five students at Purdue University Calumet. TwitrCrypt is an encrypting and decrypting application that allows users to input up to 140 characters of text. The idea for TwitrCrypt is based upon use with the social website Twitter, which allows users to write messages up to 140 characters long, but can be used by anyone who simply wants to encrypt and decrypt a text message. It works by allowing the user enter a message, encrypt it, send the encrypted message text to the recipient, and then they enter the encrypted text into the decryption portion which will show them the message in its original form.
The TwitrCrypt application was written in C#. C# was chosen primarily because the group as a whole was more experienced with this language compared to other programming languages. Experience with a certain programming language was the major factor when choosing one over another. There was no other particular reason C# was used for this application.
User Guide
How to TwitrCrypt:
1. Begin by running the program by clicking on the TwitrCrypt.exe file.
2. Enter up to 140 characters of text into the text box located next to the encrypt button. For example: “Meet me at school by five”.
3. Click the encrypt button.
4. The user should now receive output in the textbox located next to the decrypt button. This text is the encryption result of “Meet me at school by five”. The new text located next to the decrypt button should look similar to the following: “Phhw#ph#dw#vfkrro#e|#ilyh†OY<\pvFGq^%ZgJaZ,O=n?b;hG^N1″x41|$/DPUWgPtQPy'{F?^C[%u8k?Q52I6EwJr[d<=+TvT>I1imA`)oBVW,’iA&|AE>;PX&(I8*#TlcOWmZSbq”
5. The user should have also created an actual output text file of the encrypted message, which they would have chose where to save it. The outputted text file will be named something such as encryptedstring.txt. This text file can be used to send to the desired message recipient.
6. After the recipient receives either the text file with the encrypted message or just the encrypted message itself, they should copy and paste the encrypted message into the text box located next to decrypt.
7. Click the decrypt button once the text is pasted into the correct text box (next to decrypt button)
8. The original senders message should now be viewable for the recipient in the text box next to encrypt, thereby completing the process of encrypting and decrypting a message in TwitrCrypt.
Buttons and Their Actions:
Encrypt – The encrypt button encrypts the character string (the text) in the text box located next to it. The text box next to encrypt also acts as the output box for the recipient once they decrypt an encrypted message.
Decrypt – The decrypt button decrypts the character string (the text) in the text box located next it. The text box next to decrypt also acts as the output box for the message creator once they encrypt a message.
Clear All – The clear all button clears any characters (text) that are currently in either text box, allowing users to paste or type new information without manually deleting old information. This was developed for saving time and convenience.
Paste Encrypted Text – The paste encrypted text button pastes the most recently encrypted text into the decrypt text box, allowing the users to paste text into the box without having to manually perform the act, thereby saving time.
Log – The log button allows the user to view the information encrypted while using TwitrCrypt. This will act as a history for TwitrCrypt users.
Save key to text file check box. – This option allows the user to save the encrypted key to a text file if desired.
Future Enhancements
Some of the future enhancements which could be added to our TwitrCRYPT project are the ability to use the encrypt/decrypt options on a mobile device. Also some of the other features which could be integrated within our project are the ability to decrypt different type of files such as audio files, mpeg4 files as well as web files. Additionally some of the other enhancements which were suggested to us by other groups are the ability to keep a log of what was encrypted and decrypted while using TwitrCRYPT. The log would be saved and encrypted when the application closes. It will only be accessed while the application is opened so the user can keep track of the conversation. Future versions will create an archive of encrypted conversations. Lastly one of the other ways we could improve our program is by integrating TwitrCRYPT program with the TwitrCRYPT instant messenger, this would allow one to use the TwitrCRYPT as a part of IM instead of having it as a separate entity.
BehindClosedDoors
Language
Our project was written in C#. We choose this language because everyone in the group had a basic knowledge of the language. Some of the group had knowledge of other languages, but each member had different levels of knowledge and C# was the most familiar language.
Open Bugs or Unresolved issues
After correcting a problem with the program crashing with files over 1 MB, another problem of writing the decrypted file appeared. This occurs when the software tries to append the decrypted text file while it is still locked to the program. Also most speed issues were not resolved. We believe this to be an issue with the programming language choice.
Another known issue is the program will read text documents in UTF-8 encoding with out any problems. However, when decrypting a txte file that was originally from a text document in UTF-8 encoding the program deletes the original text document. When removing the piece of code that would delete the original text document, this would could issues with ASCII text files. Once finished decrypting the UTF-8 document the program would not display the content.
Future Enhancements
There are many future enhancements that could be made to this project.
The first one would be to let the user define a password to encrypt in. This would allow any password to be used as the decryption key. Encryption libraries were not to be used, so developing a more thorough encryption algorithm would make the software more secure. Another improvement to the encryption algorithm would be to apply a type of compression to the file either before or after encrypting. Currently, the file’s size doubles because for every byte it adds a password byte. To make improvements on the speed issues, an encryption library could be programmed and compiled in C or C++ and called from the C# interface. This method would drastically speed up the encryption process.
How the Tool Works
In the Behind Closed Doors application, the user will be prompted to select a text file to encrypt. The encrypted file will be saved in place and the encrypted contents displayed. The user will also be given the option to choose a file to decrypt. The application will decrypt the selected file, save it in place and display the decrypted content. The encryption algorithm does not utilize an encryption library.
HidingInPlainSight
The steganography project was developed using C# .NET based on the 2.0 framework. Our tool allows the end-user to import a bitmap image to the application, encode a message of 140 characters or greater, save the image with the encoded message without affecting the file size and lastly reopen an encoded image to display the message. This process uses least significant bit (LSB) method that takes the right most bit of a byte and removes with a corresponding message character. The process does this until every character of the message is fulfilled. For the imported bitmap image, after the included header we can begin allocating space for the message. Therefore each pixel being 32-bits contains 4 bits of a character. With every two pixels we alter, one character is stored without image loss.
During the development phase we’ve encountered the following errors via black and white box testing:
- The program accepts more than 140 characters
- The program accepts a null message to encrypt
- The file size changes after an image is encrypted smaller than 1Mb
- File sizes smaller than 1Megabyte are accepted
- Cancel button throws an error when exiting decryption process
- If the file type is changed an error is displayed
- When a parameter is passed to the program through command line an error occurs
The following enhancements have been added to the steganography project:
- The minimum image size program is 1 Megabyte if a user tries to open a smaller file an error message is displayed
- The largest message that a user can enter is 140 characters
- A user cannot enter a null message
- Error message was removed when a user cancels decoding an image
- Try-catch blocks were added to primary statements to handle any errors which went undiscovered
The following errors were unable to be repaired:
- If the file type is changed an error is displayed
- When a parameter is passed to the program through command line an error occurs
