Lockit Security

The following details the encryption and other security measuers Lockit uses to keep your data secure.

Database Encryption
Lockit encrypts all your personal information (passwords, usernames, cards, etc…) in a database file which is encrypted using the Advanced Encryption Standard (AES) in Cipher-Block Chaining (CBC) mode. The block size used is 128 bits and the key size used is 128 bits. Cipher-Block chaining mode ensures that any patterns in your data are completely concealed and randomized. Upon each save that the user makes, the database is re-encrypted using a random initialization vector (IV) of 128 bits long. By generating a random IV each time, multiple database files containing the same information and encrypted with the same key would appear completely random to an outside observer.
Key Derivation
In order to use AES 128 to encrypt the database file a key must be present. Lockit generates this key using Password Based Key Derivation Function 2 (PBKDF2) with hash function SHA256. When the user creates their master password a random 128 bit salt is created and passed into the key derivation function along with the user’s password. Lockit performs PBKDF2 with an iteration count of 10,000 in order to make brute force attacks extremely difficult. They key generated is then used to decrypt and encrypt the local database.
Random Number Generation
Lockit uses the function CryptographicBuffer.GenerateRandom to generate the IV and Salt. This method provides better randomness than calling System.Random or a similar API as it uses a system wide seed that pools from several data sources such as the process ID and thread ID, the system clock, the system time, the system counter, memory status, free disk clusters, the hashed user environment block and much more. Using multiple seed sources ensures good randomness.
Handling a Corrupt Database File
In case the database file is corrupted a backup of your last successful save will be restored. To check if a file has been corrupted or tampered with a checksum is verified when Lockit tries to load the database file. The checksum is generated on each save by hashing the encrypted data with Message-Digest Algorithm MD5 and it is located in the first 128 bits of the database file. If the checksum in the file does not match the checksum generated when loading the database, the file is assumed to be corrupt and will be overwritten with a backup file.
Syncing Data
Lockit currently uses Microsoft’s Data Roaming feature that is only available to Windows 8 applications. The database file is stored in a folder which is automatically roamed to your other Windows 8 machines by Microsoft’s secure roaming engine. Microsoft always establishes a secure connection to its servers and the database is always encrypted this ensures that the file is safe for roaming. As Lockit expands to different platforms (such as IPhone, Windows Phone, Android) a new syncing method will need to be used, at the current time we are considering using DropBox or Microsoft SkyDrive. We will update this space when the implementation changes.

For more information about Microsoft’s data roaming feature click here.