UI security topic: UI for private activities

[Lamarque V. Souza]

Em Monday 16 January 2012, Marco Martin escreveu:
> On Monday 16 January 2012, Fania Bremmer wrote:
> > Hi there,
> > 
> > In the last days we had a lot of discussions about the security topic.
> > In my team we already had a look how the UI dialogs could look like and
> > in last fridays telco we talked about that as well.
> > 
> > So here my current findings presented in a flowchart regarding "private"
> > (means encrypted) activities:
> > http://share.basyskom.com/contour/UIDesign/flowchart_PrivateActivities.pd
> > f
> 
> oddly the layout of the slider to lock i pushed in a branch now looks the
> same before i looked at the pdf :p

	Can the great "Martini" also forsee the lottery numbers? :-)

	Ok about the dialog. Just do not forget to move the "Save settings" and 
"Close" buttons from the bottom to somewhere up in the dialog to prevent the 
virtual keyboard from covering them. Just another thought, don't you think the 
dialog gives too much attention to the wallpapers? Almost all of its space is 
used to show wallpapers.
 
> > Asumptions:
> > - Mark Activity as private: toggle Button in "Create new activity" and
> > "Activity Configuration" Dialog; details see flowchart
> > - Open Private Activity in switcher: after tap a pw dialog appears
> > (similar to delete dialog); see validation details again in flowchart;
> > currently we still have a resize issue here, see
> > https://bugs.kde.org/show_bug.cgi?id=288426
> 
> only issue i see how to do a good ui in a safe way (ivan can tell more
> about this)

	What about the case where the current activity when booting the system 
is private. Does the switcher works before opening any activity? If not then 
we will need a second dialog to ask for the password.

	I will try again to solve the resize issues in bug #288426.
 
> > - Most discussed topic has been the re-encryption of private activities
> > in case of shutdown and lockscreen. My suggestion is the following:
> > 1- after changing activity: last private activity encrypts again,
> > requires again pw if switched back

	I would rather leave the private activity open (un-encrypted sounds 
technically wrong since it is still encrypted) until the user explicitly tells 
PA to close all private activities or a lock screen happens. If the user needs 
to momentaneously do something in another activity it is very annoying having 
to type the password when coming back to the previous activity.

> > 2- after shut down: all private activities encrypt again, pw needed for
> > every private activity
> 
> +1

	+2

	Are we going to use only one password for all private activities or one 
password per activity?
 
> > 3a- after manual or automatical screen lock while private activity is
> > running: pw dialog in lockscreen is required to open the current private
> > activity. Unlock with normal activity running doesnt require any pw, it
> > behaves like Plasma Active currently does.
> 
> my only concern is that besides requiring much more logic, i have some
> concerns with that:
> * the unlock screen will become quite crowded (there was already the idea
> of adding controls for shut down, so would be yet other stuff on top)
> 
> * would require working on screen keyboard there, and is not possible by
> design, no window should ever be able to be on top of the lock screen,
> otherwise i can easily write an application that bypasses it and obtain
> unlock of the device, if the keyboard is able, also others will be (or a
> copy of the keyboard be in the screen locker itself, but this means
> bumping the memory consumption significantly)
>
> maybe there are technical solutions for the last one (if someone know
> please speak) but if there aren't it would actually decrease the security
> quite a lot

	Can't you dlopen the virtual keyboard library the moment before locking 
the screen and release the memory after unlocking? Hmmm we would have the 
problem that in case there is no enough RAM memory then there will be no 
keyboard to unlock the screen :-/ or the lock process will fail completely.

	We can also use a digit-only keyboard (only numbers), there will be less 
keys and then less memory needed to compose the keyboard. We need to check if 
it really saves enough memory. The problem is that we will need to use that 
same keyboard when asking for the password in the activity configuration 
dialog or the user may type non-digit characters when configuring the 
activity.
 
> > 3b- there has been the idea that after locking, PA encrypts all private
> > activities again and just shows the last "normal" activity as a
> > fallback. What I dont like here, that the last normal activity can be
> > completly random, so that for the user that wouldnt be a benefit, as he
> > has been just working on the private activity.
> 
> that's basically the behavior on the desktop when the current activity gets
> stopped/deleted, don't think would look too much weird
> 
> technically we would be forced to do that anyways, since when the activty
> would be stopped we have to switch to something else because it can't be
> none running.
> just depends if this has to be hidden in some ways or not
> 
> > 3c- Another option would be that the uncrypted fallback is always the
> > introduction activity, which can therefore be never private and can
> > never be deleted. This would assure that we have at least one
> > "normal/not private" activity in the system we can always fallback to. I
> > dont like this option that much neither, because we would introduce some
> > kind of homescreen, that we just wanted to get rid off ;)
> 
> could be the easiest to do, but yes, would look weird the fact that there
> is a "special" one
> 
> > - With all these passwords coming now into PA, I suggest having a
> > security tab in our settings app with these options:
> > - device pw after shut down: toggle on/off; on is default (needs then to
> > be entered in first introduction activity)
> > - edit pw for device pw
> > - device pw after lock screen: toggle on/off; off is default
> 
> i still think that if there isn't full disk encryption a device password is
> far worse than useless, because it's a false sense of security, if the
> device gets stolen the additional security it gives would be zero

	I agree. A device password is only effective if you can check it before  
booting the kernel. After that you already missed the opportunity window to 
check the system integrity. Without proper hardware support, that we will not 
have, the best we can do is using the bootloader to check the password, even  
that will not help us against offline attacks since the bootloader can still 
be overwritten.

-- 
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/active/attachments/20120116/a98cfbdd/attachment-0001.html>