| intro |
| remarks |
| help |
| screens |
This is the most critical application for my mobile device. I want to always have all the details on my passwords, credit cards and other confidential data with me, but the danger of abuse is high: I could loose my mobile device or it could be stolen or somebody could just have a look at it while I'm away.
So the confidential data must be encrypted with a commonly acknowledged secure algorithm. For this I must have a good and long master key, otherwise the best algorithm is useless. But I hate entering a long key each time I want to lookup a password. So I'll use a shorter key for accessing the data. I'll have to enter it when I start the application, but also each time I lookup some data, if I did not use the application for a few minutes. With this shorter key the master key can be decrypted and used for decrypting the data. If I (or somebody unauthorized) would enter a wrong short key repeatedly (3 times), it would be deleted and then I would have to enter the long master key before being able to create a new short key and access the data.
While it is possible to decrypt the master key by brute force attacks, I do not believe that the casual thief would do it. First he would try the short key a few times and then the encrypted master key would be deleted and without knowing it there is no chance to decrypt the data. But maybe I'm wrong, so encrypting the master key and using the short unlock key is only an option not enabled by default. But still the master key should be long and composed of mixed case letters, digits and special characters and this is hard to enter each time you start the app.
If the Java cryptography API implemented in the Android system would not throw an exception when trying to decrypt with a wrong master key, it would be much easier to defeat brute force attacks and make hackers go crazy because for all keys entered some plausible result could be presented and only the user would know that decryption was successful by having a validation text entered by himself decrypted with the key. Such a solution was developed by a German research institute (see http://www.mobilesitter.de/en/technic.htm), but they had to implement a proprietary crypting mechanism. Maybe someday I'll find an open source package permitting me such a solution.Another serious risk doesn't concern myself, but everybody else: who knows for sure that the program is not transmitting the confidential data to an obscure destination on the internet? The Android architecture gives confidence: when installing the program you see the special permissions the program needs. Without the permission for Internet access there is no way for the program to make direct connections to the Internet, but with this permission everything is possible.
More screenshots