kwallet needed on smartphones?

[Bernhard Reiter]

Hello,
here are some more thoughts on the question if we should keep the kwallet or a 
related service on the mobile platform. The question came up after we had the 
first N900 kmail-mobile packages distributed on a few more machines within
the Komo3 project and connected them with our test Kolab Server.
Yes, we've got pestered by kwallet dialogs. ;)

Currently I believe that 
we want to keep kwallet to protect credentials if the device is turned off now
and we might use it for a higher protection layer later.

Bernhard

Read on to find out how I got to this conclusion and more:

Let us assume we have a  user called Karl.
The main motivation of Karl is that he can easily use the services he wants to 
use, but of course nobody should get a hold of the credentials and see his 
personal or business related communication. So Karl will follow a basic 
security policy of his company if he can understand it and it is not too much 
hassle.

a) Karl will keep his device running most of the time and during this time he 
does not want to enter a passphrase for the service that are running 
constantly. Like for checking emails.

b) Sometime Karl powers his device off.  For instance he leaves it in the 
locker when he does sports. In this situation he would want some basic 
protection of the credentials saved on the phone.

c) Sometimes Karls want to sell or buy some stocks via the device, taking a 
couple of minutes. His company is sometimes giving him a confidential 
document with prices that he has to check when he is on the road. He will sit 
down in a hotel or a parking spot and work on this for half an hours or more.
Of course Karls wants nobody to be able to do money transfers for him or see 
the documents. 

Let us go through the situations from a technical angle:
a) During this time the password will be in volatile memory (maybe serveral 
times) and it is quite like that it can be accessed by several applications. 

b) Without the password will be in the non-volatile memory of the device 
somewhere like N900s flash card. If it is encrypted, the encryption key will 
have to be entered by the user once the password should be used. As the 
encrypting function is known, given access to the saved state, it can be 
attacked by brute force, trying all possible passwords.

Currently with most phones, the user only enters the PIN which often is a four 
or a few more digits number. With smart phones like the N900 this step can 
even be skipped which disallows access to the GSM card, but keeps access to 
the memory. The gsm card will lock the user out after three bad PIN attempts, 
so it cannot be attacked by trying all combinations easily.  But as a key for  
a saved password it is not enough. A few digits number is tried pretty 
easily.

Practially on N900 the password will be there just in memory. As an attacker 
you can just start up the phone, copy the data. If we could access the PIN 
from without our applications this would not add much protection.
More protection can only be gained if we allow a better password to be entered 
by the user as key or we save the key in the SIM cards memory.
Using the SIM card memory can potentially be hard and this solitution would 
render the device less useful in case no simcard is there.

So my conclusion is to keep kwallet and make sure the encryption function is
expensive enought  - needed long computational operations - that the entropy
of entered passwords is offering some real protection.

Once fully disc encryption is there, we could do without kwallet, but full 
disc encryption would face the same problem how to get a reasonable key.
Given that full disc encryption might be designed by the device manifacturer, 
a use of the SIM card or another smart card sound plausible, then the PIN 
might be enough.

c)  Karl is watching my phone very closely in this situation and it is okay 
for him to do some steps to get into the mode.  Let us call this high 
security mode with high value credentials.
If the credentials are only kept during the operations this provides at least 
some protection against the attack within memory of the device. So our 
service would need a reasonalbe timeout after which the password is 
forgotten. Of course the problems with the saved password from b) above 
apply, but kwallet could do more checks for the quality of the used password.


-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2620 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-mobile/attachments/20100601/13ee8571/attachment.p7s