The primary goal of Annals was safe, easy, and secure journal keeping.
This page will explain how we protect data.
All encryption is done using AES128 with a 256bit key, and hmac computation is done using SHA256, and key generation hashing uses SHA512
Each shelf is protected by a seperate password, so that cracking one shelf won't get them every entry in every shelf.
This password is used to protect the encryption keys for each shelf.
It is run through PBKDF2 a large number of times to generate a derived key and a derived hmac key, and to slow down key guessers
This is used to decrypt the master key, master hmac, overview key and overview hmac.
Each item, and its associated attachments are encrypted using per item keys
Data we need more frequently such as tags and locations are encrypted with the overview key
We keep only unlocked and in memory what needs to be unlocked for basic display
Additionally, we store information about key type and size, so that should upgrades in algorithm or key size be needed, we can do that
When an entry is created using QuickEntry, an entry key is generated as normal, and used to encrypt the entry, and any attachments. However, instead of the entry key being encrypted with the shelf master key and stored as above, it is encrypted using the shelf public key. We use Apple's SecKeyCreateEncryptedData to do the encryption using the 'kSecKeyAlgorithmRSAEncryptionOAEPSHA512AESGCM' constant, which generates a 128 bit AES session key to encrypt the entry key with, and then encrypts the session key using the public key.
When a shelf is unlocked, the entry keys of any QuickEntry entries are decrypted using the private key (using the reverse of the above), and then reencrypted using the symmetric shelf master key.
QuickEntry support is per shelf, and also per device for all shelves on that device. You will be asked if you wish to enable QuickEntry on each device when you unlock a shelf with it enabled, and it can be turned on or off at any time in the settings.
On the Mac, QuickEntry is done via a helper process that controls syncing and can run as a status item. This helper has no access to your decryption keys, and communicates with the main app via a secure XPC service.
The two most likely threats are a weak or easily guessed password, or that we screwed up. We do our best to ensure the safety and integrity of your data, but we won't try to claim perfection.
Next is an unlocked journal on a device, export functions are password protected, but the master keys of any unlocked shelves are already in memory.
There is also a possibility of inferrence drawing via the unencrypted meta data
There is a final possibility, and that is if you choose to use iCloud to sync, and someone compromises the layers of protection surrounding that, and then gets through all of the above as well
We chose to use Apple's CloudKit for two main reasons. Ease of use, and security
We already have experience syncing with CloudKit so the libraries were similar. Syncing is fast and easy for the kind of data we store
But what of security you say? It's the cloud, surely it isn't secure
First, all of the above happens on your devices, before we ever sync anything to Apple's end. Second, communication with iCloud happen's exclusively over https, using Apple's own libraries. Third, all Annals data is stored in your private database, and is encrypted on their servers using your account's keys.
For more information on iCloud security, see Apple's white paper
There are some steps one can take to increase the security of one's journals and devices in general.
This is by no means a list of every security precaution, but its a good starting point