Home · All Classes · Annotated · Functions

SXE - Package Keying and Manifest

There are three control files governing the install time and run time operation of the SXE with respect to packages and programs.

The table below summarizes the operations of the system with respect to packages and programs.

Rekeying

SXE relies on shared secrets which is the principle that a key is kept secret to the server process qpe and to the program owning the key. No other program should know or discover that key. The key is simply a long number generated randomly.

One way to attack this system is to try to guess the secret key.

SXE keys are 128 bit and trying all possible keys would take thousands of years even assuming a very fast processor.

Since a key guessing ("brute-force") attack is not feasible, a common attack is to discover information about the random number in the key.

If the attacking downloaded program has some information about the /dev/random device, this means only a smaller subset of numbers needs to be tried. In this case we say the effective entropy of the random number generator (RNG) has been reduced.

If it is possible to attack the RNG in this way, that constitues a flaw in the security of the product, most likely at the OS level; and is a bug that needs to be fixed.

As a second line of defence, to mitigate the risk of an exploit of an RNG bug (or a similar security flaw), keys are changed periodically. The period is governed by the macro QSXE_KEY_PERIOD and it is not recommended to change it from the default of approximatley 2.6 days.

As an example, if an attack on RNG reduces the entropy from 128 bits to 40, and the attack program is able to try 10 keys a millisecond, then the chance of a successful trial in a 2.6 day period is: ( 10000 x 60 x 60 x 24 x 2.6 ) / ( 2 ** 40 ) = 0.2%.

Without rekeying that figure increments by 0.2% on each period. The expected outcome (for an average device over a large number of devices) is that the attack program would find the key when the figure reaches 50% ie in 636 days. Alternatively, for every 1000 devices attacked by the program the expected outcome is that approx 3 devices would be compromised every 2 days.

With rekeying there is no relationship between trials in successive periods so the probability of a successful attack does not grow larger than the 0.2% for any given period, despite the exploit on the security flaw in the RNG.

In the case of a device with a unique id number, such as a GSM phone's IMEI number the process keys are further hashed with the key. This makes blanket attacks - where large number of end-user devices recieve a malicious program - much more difficult since obtaining the IMEI number is a privileged operation.

Rekeying also means that if a rogue program somehow manages to obain a key and is is not discovered it will only be able to operate until the key is changed.

If a Read-only file system such as cramfs is used to store program binaries, or they are for some other reason read-only, then it is not possible to rekey those binaries.

Instead the new key is written into a .rekey file inside the directory $QPEDIR/etc/sxe. This directory must be protected by a LIDS policy where each program progname only has read-only access to $QPEDIR/etc/sxe/$progname.rekey.

This makes the security policy more complex, and therefore theoretically less secure. It is preferable that the Qtopia binaries can be stored on a writeable file-system, but SXE will still work with a read-only filesystem.