This is a problem that people have been harassing for many years, and any reasonably motivated person with skills will be able to find ways to find out what information you do not want them to know if this information is ever stored on the device.
Without jailbreak, you can disassemble applications using a purchased or downloaded binary. This is a static inspection and is facilitated by standard disassembly tools. Although you need a tool that is good enough to add characters from the linker and have a good understanding of method calls in order to be able to tease what happens. If you want to understand how this works, look at hopper , it is a really good tool for disassembly / reverse engineering.
In particular, for your secure journal, you have a big problem if you have a motivated attacker: the man-in-center system attacks. In this case, the attacker can pin the network code used by your system and see everything that is sent through the standard network. Therefore, you cannot depend on the ability to send any form of unencrypted data to a "secure" channel at the OS or library level and expect that it will not be visible. At a minimum, you need to encrypt before receiving data in the pipe (i.e. you cannot depend on sending plain text to standard SSL libraries). You can compile your own set of SSL libraries and link them directly to your application, which means that over time you won’t get any system performance and security improvements, but you can manually update your SSL libraries if necessary. You can also create your own encryption, but this is fraught with potential problems, as it may be easier for motivated hackers to attack your wired protocol at this point (publicly tested protocols such as SSL are usually more secure than what you can put together if only you are a particularly talented developer with many years of security / encryption experience).
However, all this suggests that your attacker is reasonably motivated. If you remove low-hanging fruits, you can prevent a random hacker from making a simple attempt to figure out your system. Some things to avoid:
- saving plaintext encryption keys for either side of the encryption
- storing keys in specially named resources (a file named
serverkey.text or a key stored in plist with a name containing key is classic) - Avoid simple passwords where possible.
But the most important thing is to create systems in which the keys (if any) stored in the application itself are useless without information that the user must enter (directly or indirectly through systems such as OAUTH). The server does not have to trust the client with any important operation without any interaction with a user that can be trusted.
Apple Keychain provides a good place to store authentication tokens, such as those received during the OAUTH sequence. The API is a little tricky to work with, but the system is solid.
In the end, the problem is that no matter what you do, you simply bet on the amount of work that is required to defeat your measures. The attacker gains control of all the important parts of the equation, so they will ultimately defeat anything on the device. You will need to decide how much effort needs to be done to ensure the security of the client, as well as to protect the server and control abuse. Since an attacker holds all the cards on the device, your best approach is methods that can be implemented on the server to enhance your goals.