HOWL application.

Created by Team HOWL. 

• Jason Panovka 

• Nicholas Florian

Technical details:

Our app is a peer to peer message service which uses a BlockChain to authenticate messages. The app will be developed for the Android platform using Java and C++. Several built in features will be used for the function of our application. For the APIs generated by google we must agree to their license https://developer.android.com/studio/terms.

List of APIs:

• BlockChain (Native, Developed by us)

• OpenSSL (Apache Free Use license)

  • We will base our BlockChain on Bitcoin, but will use the encryption functionality developed by OpenSSL.

• Bluetooth Android API (Native, Developed by Google)

• Rooms DataBase API (Native, Developed by Google)

  • Blocks/messages will be stored using the Rooms database, native to the Android platform. 

• EncryptedSharedPreferences for storing public and private keys. (Native, Developed by Google)

• Java Native Interface. (C++ to Java)  

We will be referring to the Google developed Bluetooth Chat sample app in order to help us navigate the Bluetooth API:

https://github.com/android/connectivity-samples/tree/master/BluetoothChat

We can create a bottom tab view (specified in our UI mock up) by following these instructions: https://code.tutsplus.com/tutorials/how-to-code-a-bottom-navigation-bar-for-an-android-app--cms-30305

All icons will be generated using the Image Asset Studio which is built into android studio. The logo itself may be drawn using the SVG software Inkscape.

The app will be stored on Github.com. We will use Trello to track the completion of requirements.

Explanation

Our app is a secure bluetooth, peer to peer messaging app. The app allows for conversations between two users (called chat rooms), the messages are stored using a Blockchain in order to guarantee the authenticity of the sender. The Blocks themselves are encrypted using RSA in order to secure information sent openly over Bluetooth, the Blocks are sent along with a unique ChatId so the user knows which blocks build which chains. 

Whenever the users come into Bluetooth range the app will automatically exchange their blocks. The app will also exchange blocks between users who don't have a chat room together (non-recipient users), this way the app can expand its signal range.

Howl BlockChain

The API for the block chain will be developed in C++ using the OpenSSL security library to handle encryption operations. The blocks will be hashed using the SHA-512 standard and encrypted using the RSA-512 standard. This API will be responsible for representing the object in memory, performing these operations in C++ will preserve the security of the application. The API will have no memory leaks. The code will interface with the rest of the Java application using the Java Native Interface.

The BlockChain will be used in order to guarantee the authenticity of the messages sent over an insecure method such as Bluetooth, the BlockChain employs several methods in order to guarantee this. 

The two users exchanging messages in a chat room will both employ a set of private and public keys, the public keys will be provided to others in order to facilitate encrypted communications. Each user will generate a unique key pair for each chat room. Both users will also exchange a hash of their MAC addresses (UserIds), the users will combine their UserIds and hash them again to generate a unique ChatId. 

Each message is turned into a Block containing several items. Each message is salted with all members of the block including:

• The version (the messages order in the chain).

• The nonce (an incremented value to facilitate proof of work).

• A String containing the Previous Hash.

• A String containing the Current Hash. (A hash generated with proof of work)

• A String containing the Merkle Root Hash. (A hash of all previous hashes combined)

• A String containing the message. 

• The time the block was created. 

The hashes are generated as a series of bits but will be stored in hexadecimal using chars. The current hash is generated with a Nonce and a proof of work of 3. The Nonce is incremented until a Hash containing 3 ‘0’s at its start is obtained. Since the Blocks are salted with the time the message was created, no two hashes will ever be the same. 

Once a block is successfully generated, it is converted to a JSON string and then encrypted using the recipient's public key. It is stored hexadecimal along with the ChatId in the Pending DataBase. Blocks the user generates will be noted as a Personal Block and will never expire. However, if the message does not belong to any of the user’s ChatRooms it will sit there waiting to be shared for 72 hours, a maximum of 1000 blocks will be stored on the device at a time and the oldest blocks will be removed in order to make way for new ones. 

The BlockChain keeps a separate ledger for messages sent and received by the user. Received blocks can only be added through the C++ (/Java Native Interface) API if they have been encrypted first. The ChatId is used to provide context so the app knows where to send the encrypted Blocks. If the ChatId is a match, the encrypted Block is passed to the API with the user’s private key where it is decrypted back to a JSON string and further analyzed. First the version is checked to ensure the block being added is at the right position. Next, the block verifies if the Previous Hashes match. Then finally, the Merkle Root Hash is generated again to ensure it matches the one in the new Block. Now that all of this information has been verified the user can read the message they received. The block is then removed from pending and stored in the Received DataBase. If the version did not match, the block is instead stored in the Pooling Database and will be attempted to be decrypted again.