Keyring for Palm OS

current state

This product contains no cryptographic algorithms itself. It uses pilotSSLeay for encryption. The necessary libraries are in the binary distribution.

The master password is not stored in the database. Instead, an MD5 hash of the password and a random 32-bit salt is stored and checked against entered values.

The master password is also used to generate a record encryption key. The 128-bit MD5 hash of the master password is split into two 64-bit keys, K1 and K2. (DES ignores the top bit of each byte, so the key has 112 effective unknown bits.) These are used to generate record data encrypted as Enc(K1, Dec(K2, Enc(K1, Data))). Each 8-byte data block is independently encrypted by the same key.

A strong random number generator gathering event entropy is used to generate random passwords and the 32-bit salt.

Keyring tries hard to clear any memory address that can contain secret information, but due to the way PalmOS text field work it can't guarantee that the contents of the password fields aren't still somewhere in the volatile memory when keyring is terminated.

In general, Palm application databases are not protected on the HotSync PC, even if they contain private records. Confidential data therefore is visible to anyone who can read that file on the PC. However, Keyring for PalmOS encrypts all data except when it is actually being edited.

known weaknesses

If it is possible for an attacker to get the encrypted database he can mount a brute-force attack to find the correct password. Keyring for PalmOS provides 112 bits encryption, but that doesn't help if you have a weak master password. An attacker may try all passwords from a dictionary or short letter/digit combinations. With a 1.2 GHz PC he can check roughly 1.5 Million passwords per second. This gives the following figure:

Note that this figure only applies to amateur crackers, not to someone with access to a super computer. A good password uses at least 8 random letters, digits and punctuation characters. The author uses a 10 character random password including letters, digits, punctuation and accentuated characters (the latter makes encryption with a PC conduit more difficult, though). Keyring for PalmOS supports passwords of up to 40 characters.

Categories and key names are not encrypted. This makes it possible to browse the key database without entering the password. You should be careful not to put sensitive information in the key name. You can for example leave it empty.

PalmOS does not have memory protection between applications: a hostile application or PC-based conduit could read information from inside the Keyring for PalmOS database. Keeping records encrypted provides some protection but a trojan palm application may, for example, record all graffiti strokes to steal your password. This problem can only be avoided by not installing applications from suspicious sources.

Keyring for PalmOS uses ECB, which means that every 8 byte block is encrypted the same way. This way an attacker can see from the encrypted database which blocks have the same contents, e.g. the same account or the same password. However, he doesn't know the content of this block. It's also impossible to guess the encryption key from a known plaintext/encrypted pair. This problem should be fixed with the new crypto algorithm, see below.

There was a serious bug in version 1.0 that Keyring never removed the cached database key, even when the timeout was long over. It even stored it in a database so it is possible that it was backed up to your PC. You should make sure you use at least version 1.1 and that you don't have a file named "Keys-Gtkr-Temp.pdb" on your PC. It is also a good idea to change your password, if you have used it under Keyring 1.0 before.

You should only Hotsync to trusted computers. It would be possible to (for example) put a program on the PC that grabbed the handheld's memory image, or that installed a trojan onto the handheld. To avoid trojan versions, please download from the official site and check the MD5 checksum and GnuPG signature. My GPG key is available from the PGP key servers, the fingerprint is at the bottom of the introduction page.

random number algorithm

You can let keyring generate a random password for you. The problem here is that you can't compute random numbers. You can, of course, use a pseudo random number generator, but most are not good enough for cryptographic purposes: For example, if one would use the builtin random number generator, there is a big problem. It is often seeded by the current time only. If an attacker knows the algorithm and can estimate the time the password was generated (some web sites tell everyone the day you became a member) he can just try all possible seeds and will find your passwords with only a minimum number of tries.

For this reason keyring uses a strong pseudo random number generator. It is seeded with every event sent to keyring, that means every pen stroke and every button press and some more. The complete event structure including the coordinates of the pen stroke is used. So after you scribbled in the master password there is enough new randomness for generating really long passwords. The randomness is collected in a random pool containing 256 random bytes. New randomness is added as if it would be a huge random feedback shift register. When extracting random data from the pool a SHA1 hash is calculated from the current content and fed back to the pool on the fly. The algorithm is taken from the linux secure random generator.

plans for next version

To make brute-force attacks more difficult I plan to use PBKDF2 (see RFC 2898) for key generation. This iteratively applies HMAC-SHA1 so that it takes much longer to try a single key.

The difficulty here is to balance between speed and security. A single HMAC-SHA1 needs more than a milli-second on a PalmVx even with assembler optimized code. So 1000 iterations (which is the minimum suggested iteration count by PBKDF) need more than a second and must be applied every time Keyring checks the password.

The hash is generated from the encryption key by a single application of SHA-1. It is much shorter than the encryption key so that it makes it more difficult for brute-force attacks to check if the key is the correct one while giving enough protection against typos.

The records are encoded with CBC (cipher block chaining). The IV is generated by the secure random number generator and stored in front of the encrypted data.

There are new encryption methods supported. For DES full triple DES (168 bit) is used. There is an open source AES (under modified BSD license) that can be used for encryption. I also change the hash function from MD5 to SHA1, because it gives more bits and is the standard for PBKDF2. I will probably use my own speed optimized SHA1 version, so I can handle 1000 iterations in reasonable time.

Copyright © 1999-2005 by Jochen Hoenicke <hoenicke@users.sourceforge.net> and Martin Pool <mbp@users.sourceforge.net> .
All products or company names may be trademarks of their respective owner.
$Id: crypto.htp 799 2009-04-16 13:22:29Z hoenicke $