Anelok: UI walk-through, authentication idea, better timing, power-saving
werner at almesberger.net
Mon Mar 30 20:44:49 UTC 2015
I made a first attempt at implementing the account display. It doesn't
look particularly pretty yet but it's a start. Here is a walk-through
of Anelok's current menu hierarchy:
We start with a dark screen. Pressing "middle" brings up the logo and
releasing the sensor again leads us to the login screen. As long as
there is no input, the "setup" icon is shown. Pressing "top" leads to
the login-setup menu, which contains left/right switching, the
firmware build version, the device ID, the status of the radio chip,
and a few more technical items. (Note: all this is from the simulator.
IDs are different on the real device.)
Entering the correct pattern at the login screen leads to the account
selection list. Once more, there is a setup option, which at the
moment leads to a dummy menu. Try to select anything, and out comes
the apologetic ghost. That ghost also appears at many more places
where the respective next screen hasn't been implemented yet.
Selecting an account shows more detailed information: the account
name, a URL (or similar), the user/login name, and the password. Right
now, all this is pretty uniform but there could of course be more
I show two example accounts, a quite generic account ("Mail"), and one
where the password isn't shown ("e-Bank"). When scrolling down to the
password and pressing "middle" (see the eye icon), the password is
revealed. If any additional communication channel is available, this
is then indicated. In this example, there would be the option of
sending the password over a radio link.
If you try the simulator, you'll see two more options: a keyboard icon
for "typing" the password via USB HID, and "exchange" for more
structured (encrypted) communication.
A quick idea for authentication: while pecking at the slider is all
nice and fun, it's also pretty inefficient in terms of slider input
vs. authentication bits we get. I had the following idea: Anelok could
move a "pen" back and forth along the X axis, and draw a line at the
slider's Y positions. The resulting pattern could then be matched
against the one the user has stored before.
- refine this to a point where it's actually human-usable (e.g., it
may make sense to add some grid / markers to help users get their
- find / develop an algorithm that can do such matching,
- determine just how much entropy it really provides,
- while less critical in this case, it would be nice if the algorithm
would make it difficult to reconstruct the original pattern from the
information stored in the device, much like passwords are hashed.
Back to current reality: I reduced the delay and movement thresholds
for the slider:
Parameter Before After
---------------------- ------------ ------------
Tap time 100- 300 ms 20- 200 ms
Press time 500-2000 ms 300-2000 ms
Swipe delay 200 ms 50 ms
Minimum swipe distance 20 positions 10 positions
Furthermore, swiping now scrolls by two pixels for every position on
the slider, instead of just one.
As a result, the slider now feels a lot more responsive than it used
Last but not least, power-saving. I won't bore you with another
current plot this time (but don't worry, we're not done with them just
yet). Instead, I have some data on power consumption in power-saving
In "Active" state, the display is on and shows content. Battery
current is around 15 mA, depending on how many pixels are lit. If the
device is doing something else, current would be higher.
I now implemented a timeout for the UI, and Anelok leaves "Active"
state after 30 seconds on inactivity. The next lower-power state is
"Dark1", where the display is cleared but still powered. This
already reduces the current to about 3 mA. If the user touches the
slider, Anelok will immediately return to where it was before.
The idea is that, if the user is reading something from the screen
and needs a bit more time, a quick tap is enough to immediately bring
back the display.
If nothing happens during ten seconds, Anelok goes to "Dark2", where
the display panel is powered down. This currently also returns the
device to its de-authenticated state (i.e., one has to enter the code
when powering on), but I'll decouple this from power-saving later.
There are a few exceptions. E.g., some screens (login, ghost, etc.)
go directly to Dark2. Also, login times out after only five seconds
Deeper low-power modes are possible, e.g., by turning off the boost
converter and by reducing the sample rate of the touch sensor. But I
haven't implemented any of this yet.
More information about the discussion