anelok: to switch or not to switch

Werner Almesberger werner at
Tue Jan 7 00:41:37 EST 2014

The switch is one of the more troublesome components of Anelok.
It currently has the following issues:

1) role not clearly defined (see below),
2) quite big (could get a smaller one, see below),
3) access is a bit fumblish since the switch is small in
   relation to human fingers and it also has to be protected
   against accidental operation and shear forces.

The one I currently have is also a potential sourcing risk
because I know only one source for that form factor. But see

Uncertain role

Right now it's designed as battery cut-off but that may not be
such a great idea since

a) we need a bit of battery power to feed the RTC and therefore
   have a bypass resistor (R9) that allows a small current to
   flow even if the switch is off, which leads to

b) if the MCU doesn't drop power consumption quickly enough,
   having such a current limiter may cause the MCU to crash
   and/or oscillate through reset.

Also, we still have the 220 uF silo C15 behind 100 Ohm (R5)
that could let the MCU still do some dirty things every once in
a while. And there will be more silos - and without limiting
resistors - for those inrush currents.

Rfkill ?

So perhaps the switch shouldn't cut power. How about rfkill ?
That would let the MCU run unhampered but it would disable RF
even when under USB power (which the current power switch
can't prevent since the various power sources are mixed inside
the MCU).

A "hard" rfkill would have to switch (*) the RF supply from
Vsys to ground. The MCU could then detect the state via a sense

(*) An interesting detail is what happens while switching:
    there are switches that go 1-2 -> - -> 2-3 (non-shorting)
    and there are switches that go 1-2 -> 1-2-3 -> 2-3
    (shorting). The data sheets don't always specify this. We
    would want a non-shorting switch because shorting Vsys to
    ground would be a sure way to reset the CPU and to lose the

Such an arrangement would mean that the RF subsystem can't
provide a crystal-based clock when rfkill is active, either
making rfkill act as USB-kill too (messy) or requiring the
addition of a dedicated crystal for the MCU.

Threat analysis

Now, what would rfkill protect us from ? First of all, hostile
firmware that sends our secrets to our enemies. But it could
also leak things by accident, e.g., if there is an expliotable

Furthermore, RF could be used to detect the device's presence,
either by listening for things it sends or for trying to get
its attention. I haven't looked much into the BTLE protocol, so
I don't know what level of activity would be expected from a
station that is idle.

Of course, if we trust the firmware to at least get a basic
software rfkill right, then one could simply turn off the
transceiver by software.

A threat analysis would also have to consider an attacker with
physical access to the device to simply bypass the switch.

Considering all these things, the utility of the switch still
remains somewhat dubious. It would defend against attacks that

- compromise the firmware,
- have no or only very limited physical access,
- rely on RF for
  - leaking data (*), or
  - announcing the device's presence, e.g., to detonate a bomb
    if you have that sort of enemies.

(*) An alternative channel rfkill couldn't block would be to
    have the compromised firmware store data on the memory card
    or in the MCU and having the enemy access the card/MCU in
    some way later on.

Second source

Meanwhile, I kept looking for smaller and less risky switches
and I finally found this pair:

- Copal CUS-12B


They seem to be identical. They're a bit more expensive than
the current one but much flatter (1.4 mm vs. 3.5 mm) and having
two manufacturers to choose from means that the risk of
untoward surprises is low.

- Werner

More information about the discussion mailing list