Werner Almesberger | 23 Jan 04:24 2016

Anelok: CC2543 vs. nRF51822

A while ago I discussed the Anelok design with Bluetooth hacker Mike
Ryan, and he strongly recommended using the Nordic nRF51822 instead
of the the TI CC2543.

The idea for the TI CC2543 is to write the lower layers of an open
BTLE stack from scratch, and at some point mix this with the upper
layers from BlueZ.

The main benefit of this approach is that it's 100% open. The main
drawback is that it's a lot of work, especially given that the
hardware doesn't quite support the BTLE frame format, and thus would
require some creative software tweaks.

After looking (again [1]) at the nRF51822 documentation, I'm now
reasonably confident that one could write an all-Free stack also for
this chip. But it has the added benefit that Nordic provide a
(closed) stack as well, which should help to keep the development
time for a first working prototype down.

Another feature that may become important given recent regulatory
trends is that the nRF51822 (like the Kinetis MCUs) can be protected
against unauthorized Flash modification. I.e., one could write a
boot loader that only accepts signed binaries. The CC2543, on the
other hand, can always be fully erased and then accepts any new

Further advantages of the nRF51822 include that it's a Cortex M0
(so we don't need SDCC for the ancient 8051 core of the CC2543) and
that it has enough Flash and RAM for the entire BTLE stack. That may
end up weakening the role of the cMCU, but I think any possible
(Continue reading)

Werner Almesberger | 17 Jan 01:33 2016

Anelok: "2015" version

Anelok has a naming problem: the "2015" version is still the current
design in 2016, and still unfinished.

I could just prepare to explain a lot of times why "2015" really means
"2016", or simply bump it to 2016, but maybe the concept of naming
major design revisions by date has outlived its usefulness.

How about using the "mark" numbering scheme instead ? E.g., "Mk 3" ?

The name change would be as follows:

Now	Then	What it is
----	----	----------------------------------------------------------
2013	Mk 1	The ancient design with jog wheel, 802.15.4, and CR2032
2014	Mk 2	The current prototype with touch, 802.15.1, and CR2032;
		i.e., what's shown on http://anelok.com/
2015	Mk 3	The next version with tact switches, 802.15.1, and AAA;
		i.e., except for the switches, this is what is shown on

In file or directory names, "Mk N" would become mkN.

How does this sound ?

- Werner

Werner Almesberger | 15 Jan 18:42 2016

Anelok: more firmware improvements

Some more new firmware features:

- The account database code was fairly inefficient, and decrypted
  records way too often, e.g., also when only stepping through the

  It now uses lazy decrypting. Also, the directory code is now much
  more efficient and robust.

  All this means that navigating a real-life database (with 45
  accounts so far) is now without noticeable delay.

- To measure delays, I added a performance monitor. It is enabled
  in the setup menu on the login screen ("Perfmon on/off"). When
  the performance monitor is on, it displays the number of
  milliseconds it took to process the last tap.

- The sideways scrolling had a nasty bug: if the line was partially
  outside the visible display area, the code tried to draw pixels
  off-screen. display_set and display_clr oops in that case.

  This was somewhat tricky to track down. The "oops" code so far
  only showed at which line the problem was detected. Now it also
  displays a stack trace. You can test this (also in the simulator)
  with "Panic" in the login setup menu.

  Speaking of the simulator, debugging this issue would have been
  very easy there, but it didn't have the same draconian sanity
  checks in display_set and display_clr as the real firmware. Now
(Continue reading)

Werner Almesberger | 15 Jan 16:00 2016

Anelok: towards KiCad 4

This is a somewhat long story about the journey towards KiCad 4.
This journey is still not over, but I'm beginning to feel that it
may have a destination that is not a circle.

It all began with an Ubuntu update last December. My 14.04 LTS
("Trusty") was getting long in the teeth, so I thought it was time
to upgrade to "Wily" 15.10. Alas, when trying to trick the upgrader
into going from LTS to non-LTS, I ended up with "Xenial", the
experimental 16.04.

This caused a number of problems, e.g., Chromium failing to do SSL
with Google services (but getting along with most of the rest of the
world), and Xfig becoming very eager to segfault, but eventually I
solved all that.

However, one big problem remained: KiCad. I had been using an older
version of KiCad (I think it was bzr 4150), but some of the libraries
it depended on were no longer available under Xenial.

As it happens, new and shiny KiCad 4 (bzr around 6400) had been
released recently. Since holding on to an increasingly distant past
is usually not the most sustainable of plans, I decided to try moving
on and to welcome the new.

The first thing I tried was to see how pcbnew performed. When I had
poked at newer KiCad versions before, I had always experienced
extreme slowness in the "legacy" canvas. The OpenGL canvas was snappy
but lacked (and still lacks) some of the functions available in
"legacy", so one has to switch back and forth between the two.

(Continue reading)

Paul Boddie | 5 Jan 01:30 2016

Recent Stuff: Nitrokey Storage and EOMA-68 jz4775 Board

Happy New Year!

The forwarded announcement below appeared on the FSFE discussion list. I 
thought it might be interesting to compare the promoted device to Anelok given 
that it is targeting the password management application of Anelok, although 
it is also bundling support for other things. The crowdfunding page is, as 
usual, heavy on the promotion and light on the technical details, but it may 
also be informative about demand for such things (or if people are merely 
baffled by them).

Meanwhile, for those still hoping for a successor to the Ben, it's perhaps 
also interesting to see that the EOMA-68 initiative is making progress on 
delivering a jz4775 version of the PCMCIA profile card with 2GB RAM on board:


And with these two areas covered, hopefully almost everyone here will be 
happy! ;-)


----------  Forwarded Message  ----------

Subject: Crowdfunding USB Security Key for Encryption - Nitrokey Storage
Date: Tuesday 22. December 2015, 14.36.00
From: Jan Suhr <jan <at> nitrokey.com>
To: Discussion <at> fsfeurope.org


(Continue reading)

Werner Almesberger | 2 Dec 23:24 2015

Anelok: firmware improvements

In the last days, I implemented a few long-planned features in the
firmware, with the overall goal of making Anelok suitable for
daily real-life use.

These features include:

- Anelok can now use multiple account databases, selected by the PIN
  the user enters. This way, I can have the demo accounts with the
  default PIN (the "V"), plus my real accounts with a different PIN.

  The overall account database structure is still something that's
  only sufficient for the present state of development. E.g.,

  - the account database is stored in the Flash of the
    microcontroller, not on the memory card,

  - Anelok can only read the database, but it cannot modify it or
    add new accounts.

  - there is no support for multiple readers yet

  - the PIN is currently stored with the keys, and keys are selected
    by comparing the PIN with what the user entered. We could do
    much better:

- The account database now supports directories. To put an account
  in a directory, one simply prefixes its name with the path. Anelok
  then figures out what to with it. This is the current demo
(Continue reading)

Werner Almesberger | 9 Nov 00:46 2015

Anelok: scripted simulations

The simulator has learned some new tricks: now simulations can be
scripted, e.g., to implement unit or regression tests.

It all started with a bug that's been around for a while and that
I finally wanted gone. That bug was that Anelok would not drop
the authentication even if idle for a very long time. The fix is


Now, how do you test this ? Having to wait more than five minutes
for each test is a bit annoying. And so would be having to change
the timeouts to a shorter value and then changing them back.

The solution is of course to use the simulator and make it run in
accelerated virtual time, not real time. Tweaking time is easy, as
countless Hollywood-made documentaries on time travel illustrate.

Since I also wanted to have better access to the display content,
I first upgraded from SDL 1.2 to SDL 2.0. That turned out to be
more tricky than expected since

- in SDL 1.2, everything you can draw on is a "surface", while
  SDL 2.0 introduces also "renderer" and "texture",

- I used the drawing functions from SDL_gfx, which work on surfaces
  in 1.2 but on the renderer in 2.0,

- the renderer is basically write-only, i.e., one can't show some
  content, then modify it and show the modification. Instead, one
(Continue reading)

Werner Almesberger | 3 Nov 22:37 2015

Re: Anelok: OTF proposal

I wrote:
> During the last days, Dave and I
> have prepared a proposal and I've submitted it just now.

OTF have reviewed our proposal. Unfortunately, they rejected it.

I'm asking for permission to post the review here. Also, Dave and
I are preparing a response to the review results.

To be continued ...

- Werner

Werner Almesberger | 24 Oct 15:46 2015

Anelok: evolution update

I've slightly updated the hardware evolution diagram:


Previous versions:




Changes since May:

- added "Buttons" as user input method, praising their reliability,
  and admit that the slider performs poorly in practice.

- also extol the brutal efficiency of killing RF by grounding VDD

Regarding the slider, there's still a chance for saving it: Dave
has two 2014 (CR2032) boards, courtesy of Canaan, to give to
anyone who'd want to try his or her luck with making the slider
work acceptably. The firmware still supports buttons and slider,
with a simple switch in DEVCFG.

So, if you like sliders, have an idea for how to harness that
messy analog data, and want to get your hands on one of the rare
2014 boards, now is the time to step forward.
(Continue reading)

Werner Almesberger | 23 Oct 18:38 2015

old toner transfer paper trivia

I couldn't find my bag with the toner transfer paper I had used in
recent years (some random brand ink photo paper), so I used the one
I could find - a sheet of the venerable HP C6039A.

I had this for about ten years (luckily inside a plastic bag, so
the thick layer of oily black dust that had accumulated over the
years wasn't on the paper itself) and time has done interesting
things to it.

The first indication was when, after printing, a corner of the
paper delaminated:


I knew the coating had a key role in making toner transfer work,
but I never pictured it as a separate film.

After passing the laminator ("ironing"), the film detached
completely, yielding this:


Except for the weird splotch under the "A" of "ANELOK", the
transfer was flawless.

- Werner

Werner Almesberger | 23 Oct 10:44 2015

Anelok: tactile switches (2/2)

To accommodate the switches, I had to change the top half of the case
and add buttons. To keep things simple, I just changed the design to
make the top layer of plastic thicker by 1 mm and cut a hole into it.

Well, at least that was the plan. Then my FreeCAD-based slicer acted
up and refused to produce usable paths. After spending a good while
examining the mesh, and paths generated from it, etc., and not
finding anything the slicer shouldn't be able to handle (e.g., some
invalid mesh geometry), I finally gave up and wrote a new slicer that
operates directly on the mesh:


I also designed the button to have a retainer plate that would keep
it from falling out of the case, but that plan was defeated by my
mill not begin able to work with enough absolute accuracy in the Z
direction, resulting in the case being too fragile.

Well, perfection can wait, and until then we have scotch tape. So
here it is in all its taped-up glory:


It's about as mechanically unsound as can be (e.g., the buttons push
against the battery that in turn pushes against the case bottom that
is only held by friction), but scotch tape comes to the rescue there,

For all its sloppiness, this works remarkably well, and Anelok has
never been easier to operate.
(Continue reading)