Werner Almesberger | 16 Nov 23:17 2014

idea for a fun little security project

I had a discussion where keyloggers came up and thought of this:
if your keystrokes go to a remote location, e.g., to a VNC or
similar session, you could encrypt the keystrokes at the keyboard,
defeating any keyloggers (hardware or software) on the way.

Should be pretty easy to implement: you need USB host, USB device,
and some way to set up keys, e.g., by the remote peer sending the
key on a different channel (e.g., to the screen), either initiating
key setup directly (if it can send commands on USB) or asking the
user to initiate key setup, and the user then typing in the key.

The encryption would have to use a stream cypher to avoid simple
statistical attacks. If keystrokes can get lost on the way, there
would also have to be some "clock synchronization" scheme.

To defeat keystroke timing analysis (we won't assume that the enemy
doesn't have a few bored scientists in the their team, right ? :),
the device should add some randomness to keystroke timing.

Advanced issue: automatic session (unencrypted to local system,
encrypted to remote system) switching. If the "terminal" software
can generate local USB operations (e.g., the HID set/get feature
commands), then it could probably use that for this purpose.

Probably needs a button or equivalent to enable firmware updates.
It could use the keyboard, but that requires a fair amount of
preparation. Better to keep it simple.

One LED should do nicely: off = no encryption, on = encrypted (make
it illuminate a lock symbol), blinking = awaiting key input or some
(Continue reading)

Rafael Ignacio Zurita | 12 Nov 02:27 2014

[PATCH] anelok:sim remove include Makefile.c-common

Removing these lines let me to build the sim with cd sim/ ; make
It runs as well, but, I can not turn on the device when I click with the
left mouse button in the middle of the little screen (the "ANELOK" text
never appears).

 fw/Makefile  | 1 -
 sim/Makefile | 1 -
 2 files changed, 2 deletions(-)

diff --git a/fw/Makefile b/fw/Makefile
index 14216df..648ef0a 100755
--- a/fw/Makefile
+++ b/fw/Makefile
 <at>  <at>  -132,7 +132,6  <at>  <at>  vpath %.c $(BOARD_DIR) $(SUBDIRS)

 # Include Makefile.c-common after setting CC, etc.

-include ../common/Makefile.c-common

 # -----------------------------------------------------------------------------

diff --git a/sim/Makefile b/sim/Makefile
index 0ba6bc7..7760873 100644
--- a/sim/Makefile
+++ b/sim/Makefile
 <at>  <at>  -10,7 +10,6  <at>  <at> 
 # (at your option) any later version.

(Continue reading)

Werner Almesberger | 11 Nov 07:11 2014

Anelok: fatigue and normalization

I'm having a bit more fun with the capacitive sensor. As mentioned,
it didn't work very well. I first ran a series of tests to examine
whether changing the configuration of the touch sensing module
would improve the sensor's performance. There are about half a
dozen parameters to play with. From what I saw, it seems that the
parameters are about as good as they get.

However, I noticed that one of the two channels occasionally just
went dead for a while. Closer examination revealed that bending the
cables between the two boards had something to do with that
failure, but when I touched the cable at either end with tweezers,
the sensor responded normally (any direct contact just makes it go
off the scale).

I then suspected the battery holder. As one can see in the middle
image on
one of the traces is very close to a pad. So I moved the holder a
bit, but to no avail. I then removed it completely and began to
probe the trace. Turns out that there was a tiny invisible fracture
in the trace that probably responded to bending forces from the
cable. A bit of solder bridged that gap.

Then DFU (USB) started to fail occasionally, with an increasing
frequency. Also here, twisting the connector one way makes things
work while twisting it the other way makes them fail. I haven't
looked into that any further yet, but it'll be interesting to find
out what's happening there.

A boring finding would be another broken trace or a bad solder
(Continue reading)

Felix | 5 Nov 08:43 2014

[anelok] hackaday mooltipass competitor just went crowfunding

Yesterday they launched an indiegogo campaign to mass product their mooltipass device. The main goal is the same as anelok, help to protect passwords, but the approach they've done to do it is far behind Anelok :P

- They store credentials in flash memory, so, if you lose the device, you lose everything.
- smartcards are big and also the contacts are prone to wear or been damaged
- no RTC or autonomous battery, so you cannot implement two step auth based on timestamps
- the whole thing is BIG, even more when you have to plug the smartcard xD
- 100$ not a bargain, precisely...

So, from my point of view, Werner's approach is loooot better than this ;)

<div><div dir="ltr">Yesterday they launched an <span class="" tabindex="-1">indiegogo</span> campaign to mass product their <span class="" tabindex="-1">mooltipass</span> device. The main goal is the same as <span class="" tabindex="-1">anelok</span>, help to protect passwords, but the approach they've done to do it is far behind <span class="" tabindex="-1">Anelok</span> :P<div><br></div>
<div>- They store credentials in flash memory, so, if you lose the device, you lose everything.</div>
<div>- <span class="" tabindex="-1">smartcards</span> are big and also the contacts are prone to wear or been damaged</div>
<div>- no <span class="" tabindex="-1">RTC</span> or autonomous battery, so you cannot implement two step <span class="" tabindex="-1">auth</span> based on timestamps</div>
<div>- the whole thing is BIG, even more when you have to plug the <span class="" tabindex="-1">smartcard</span> <span class="" tabindex="-1">xD</span>
<div>- 100$ not a bargain, precisely...</div>
<div>So, from my point of view, Werner's approach is <span class="" tabindex="-1">loooot</span> better than this ;)<br clear="all"><div><br></div>-- <br>Felix
Werner Almesberger | 3 Nov 03:30 2014

Anelok: board #2 almost healthy

I now completed board #2. It has one unexplained problem, namely
that the crystal oscillator doesn't oscillate, but besides that,
it seems okay.

Fortunately, I can do most things also with the RC oscillator.
It's just a bit less accurate (relevant for timekeeping) and a
bit more power-hungry (bad for the battery and for measurements).
But I can play with all those things on board #1.

This is what the complete assembly looks like:


A bit of rework is visible at the bottom:

- the debug connector that's still needed because I haven't made a
  proper fixture yet,

- a 100 kOhm pull-up on nRESET (long yellow wire) that I added
  when experimenting with SWD. It doesn't really seem to have any
  effect, which is basically what I expected.

- the Vrf/Vsys swap near the rfkill switch. This will go away with
  the next PCB version.

I also didn't place the memory card holder because a) I don't need
it at the moment and b) there may be the risk of it shorting traces
running underneath it.

I connected the main board with the daughter board with four small
wires (a bit thinner and more flexible than a ribbon cable):


This is baord #2 in the case:


And this is it showing the current login screen (may change):


The blue tint of the OLED is an artefact of my camera. It gave me
the choice between having the perfectly white OLED look blueish
or having the perfectly white paper look yellow. Ah well ...

This is the first time that I fitted an assembled board into that
case, and I found a few issues:

- the silo capacitors are quite tall and need more space. One can
  see the bay I dremeled below the display.

- the OLED's FPC needs more room to bend. I also increased this
  space a bit it's still extremely crowded. Making the case about
  2 * 0.5 mm wider (the display is centered, so if I widen the
  case on the cable side, I also have to widen it on the non-cable
  side) should lead to more reasonable accommodations.

- the battery bumped into the bottom shell. Not sure why it did
  this now - it seemed to fit without problems when trying the
  daughter board alone. Again, a bit of dremel solved this.

- as expected, the rfkill switch is very difficult to reach. I
  should probably make a proper cap and move the switch a bit away
  from the edge. A minor detail.

The capacitive slider is now the main source of trouble. It acts
fairly erratically. Not sure whether this can be solved by better
filtering or whether I need a different sensor layout.

- Werner

Werner Almesberger | 1 Nov 02:31 2014

Anelok: brain transplant

After reaching the conclusion that getting into the KL26 on board #2
is probably beyond my power, I dug out the good old Chip-Quik [1] and
tried to let it do its magic. I think I may have removed some 32-QFN
that way before, but I don't think I ever tried 48-QFN.

At first things didn't look too promising: the alloy just wouldn't
stay near the pads. Apparently, it had oxydized quite a bit since the
last time I used it and all the slag was getting in the way. After
vigorously pushing it from the MCU, things improved - and suddenly
the chip started to move.

This is what the board looked like immediately after removal:

And this is after cleaning it:

As one can see, a few components in the immediate vicinity of the MCU
had to be sacrificed in the name of progress, but besides that, the
board suffered no damage.

I then soldered a new MCU, replaced the capacitors that had perished,
and tried to raise the board on SWD:

Phew. I've been wanting to see that for well over a month now.

- Werner

[1] http://www.digikey.com/product-detail/en/SMD1/SMD1-ND

Werner Almesberger | 31 Oct 03:09 2014

KLtab: becoming a programmer

To eliminate the risk of there being an unexplained and unobservable
interaction between the reluctant board and the Ben (acting as
programmer), I also tried to replace the Ben with something else.

Since I had a bunch of bored KLtabs at my hands, the choice of that
"something else" was easy. Also, the programming/testing fixture for
Anelok will be able to program the boards it is working on, so I'll
need to have my own programmer solution by then anyway. Just didn't
expect to have to implement it so soon ...

Anyway, I cleaned up swdlib such that it can run on a KL2x and added
a simple USB-based interface. A few things don't work reliably yet
and signal integrity seems to be quite horrible, but it's getting

This is what a KLtab programming another KLtab looks like:

swdlib is still in the Anelok repo (will move out some day):

The KLtab firmware is here:

And the rather primitive user-space tool is here:

I may eventually convert all this to be DFU-based, but the
proprietary protocol is more convenient for now.

Warning: this one doesn't have the FSEC sanity check yet. So if you
play with it, check your binaries first ! :)

- Werner

Werner Almesberger | 31 Oct 02:56 2014

Anelok: results of mixed goodness

I tortured the KLtab boards in many ways, but could never get them
to behave like the chip on the non-programmable Anelok board #2.

There is one thing that I didn't try yet, and that's completely
locking down one of the chips on the KLtab boards. The reason is of
course that this would make the board unusable - unless I implement
some clever backdoor.

But in any case, if the chip was protected that way, then it wouldn't
indicate that it can be mass-erased, would it ?

Well, I don't know for sure yet, but I noticed something else: a
while ago, I had broken the build process of the boot loader in a
way that would put incorrect data at the location of the
all-important Flash security byte (FSEC).

I reconstructed the likely version of the boot loader I had at that
time, and found that FSEC was probably set to 0xed. This decodes to:

11 = backdoor disabled
10 = mass erase disabled
11 = Freescale access granted
01 = MCU security status is secure

The backdoor is a mechanism that needs firmware support, so that
wouldn't work with this broken boot loader, even if I had implemented
such support (which I haven't). All other settings are such that I
can't get in :-(

This still doesn't explain why the chip happily announces that it
could be mass-erased, but all the other clues are there.

So the next step will be to try to unsolder it and replace it with a
new one. Let's see how much damage that does ...

Oh, and in completely unrelated news, my Ben-based SWD programmer
now requires the user to announce explicitly what protection level
the binary about to be flashed will set. If there's a mismatch, it
will politely refuse to mess things up.

- Werner

Werner Almesberger | 1 Oct 04:24 2014

KLtab: first two boards

Since KLtab is only 22 x 22 mm, one can fit four of them easily on a
5 x 5 cm piece of PCB. Here's an example with two of the four KLtabs
assembled in the minimal configuration:


In the unpopulated circuits in the back one can see holes in the center
pads. They were a misguided attempt of mine to properly solder that pad.
Unfortunately, the holes are a bit too small to get anything useful
done with them.  

I added a straightforward SWD-to-UBB pin assignment to the KLtab
schematics (lower right corner):


And this is what the corresponding cable looks like:


Apart from the center pad hole mishap, the KLtabs were as easy to make
as expected, and they both identify nicely over SWD:


- Werner

Werner Almesberger | 30 Sep 07:09 2014

KLtab - Kinetis L series Throw-Away Board

To experiment with the permission bits of the KL2x MCUs, I designed a
very simple and very cheap board. Since it's quite likely that some of
these experiments will end with locking up the chip for good, it's
important that these boards be as un-fancy as possible.

Here are the schematics:

And the layout:

The board is single-sided, but I had to cheat a little and cross
conflicting traces with two 0 Ohm resistors (R5 and R8).

The only things that are required are the MCU, all the capacitors but
C1, and a connection to some programmer on CON5. The following features
are optional:

- two LEDs going to GND (to they're lit when the CPU drives them high),
  connected to high-drive pads,
- two LEDs going to 3.3 V (to they're lit when the CPU drives them
  low), also connected to high-drive pads,
- a Micro USB AB (or B) connector with series resistors, to play with
  USB if SWD gets too boring.

Note that there's no crystal, so USB will have to content itself with
the internal RC oscillator. This should be good enough for device mode,
but may not quite cut it for host mode.

- Werner

Werner Almesberger | 30 Sep 06:45 2014

Anelok: update

This has been a very quiet month, so here's a quick update on what's
happening with Anelok: I started to assemble a second board. My plan
is to keep #1 as "known to be good" reference and use #2 for "real
life" use and for experimenting with the case.

This is what it looks like in the box:

Most of the components I soldered are under the OLED so all one can
see are the LED and a few passive components.

Unfortunately, I then hit a snag: the MCU doesn't want to be
programmed. It says it has been set to be "secure", which is
apparently something Freescale sometimes do at their fab. Secure
means that one can't debug the core, that one can't read the Flash,
and so on.

However, unless "mass erase" is also disabled, one can still erase
everything on the chip, including that "secure" flag. The chip says
that mass erase is permitted. Alas, it doesn't acknowledge or
execute the mass erase command.

So I spent some time trying to find out what I may be doing wrong,
but so far it seems that I'm doing everything right and that there's
something wrong with the chip.

Since desoldering the 48-QFN chip is a bit risky with the tools I
have, I want to be absolutely certain that the problem is not just
caused by some stupid bug in my program.

The plan is therefore to make a few "throw-away" boards to
experiment with the chip's protections and their removal, and see if
everything works as expected - including locking down the chip for
good. It's something that has to be done sooner or later anyway, but
I wouldn't have minded doing it later.

More about the throw-away boards in my next post.

One good thing that came out of all this is that I've cleaned up
libswd quite a lot. I also found that there's another project called
libswd, so I renamed my library swdlib for now - the whole package
will eventually need a better name, since it also includes a CC254x
debug/program library and also a tool that uses these libraries.

Despite all the cleaning, swdlib is still very unreliable: flashing,
say, a 16 kB firmware takes several attempts before it succeeds.
Strangely, everything appears to go well - I can read back and
verify all the settings before the last write that starts a Flash
write, but then the write ends in an access violation. It shouldn't
be able to do this at that point, yet it does. Very irritating.

If anyone wants to sink their teeth into the mysteries of SWD,
exorcising whatever is going wrong there would be a worthwhile task:

- Werner