anelok: to switch or not to switch
werner at almesberger.net
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
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.
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
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.
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.
Meanwhile, I kept looking for smaller and less risky switches
and I finally found this pair:
- Copal CUS-12B
- C&K PCM12SMTR
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.
More information about the discussion